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SZÖVETSÉG 
az 


elektronikus 
aláírásért 





Október elsején a HÍF székházában 
megalakult a Magyar Elektronikus 
Aláírási Szövetség. A szervezet, 
melyet elektronikus aláírási szakértők 
és informatikai szakemberek 
alakítottak, nyitott minden, az 
elektronikus aláírás ügyéért 
tenni akaró informatikus, jogász és 


üzletember előtt. 


A szövetség honlapja a 


http:/groups.yahoo.com/group/measz/ címen 
található. A hírlevélre feliratkozni 

a measz-subscribegyahoogroups.com címre 
küldött elektronikus levéllel lehet. 


Digitális aláírás Us. 
elektronikus aláírás 


A digitális aláírás egyes végtelenül tudatlan egyének szerint 
megegyezik az elektronikus aláírással. Még jó hogy vannak 
magasan képzett, okleveles elektronikus aláírás szakértők 
(nem digitális aláírás szakértők) akik tudják, hogy ez a két do- 
log nem egy és ugyanaz, s így ha a végtelenül tudatlan egyén 
digitális aláírást találna mondani, kijavítja őt elektronikus 
aláírásra, ha pedig elektronikus aláírást találna mondani, ki- 
javítja digitális aláírásra. Mígnem esetleg tudatlan egyénünk 
- aki előbb-utóbb meglehetősen írusztrálttá válik ezen okos- 
kodástól — a sokadik korrektúra után visszakérdez, hogy 
ugyan már magyarázzák el neki, mi az a digitális aláírás és 
mi az az elektronikus aláírás, meg egyáltalán mi a kettő közt 
a különbség. 

A nyilvántartásba vett elektronikus aláírás szakértő erre he- 
beg-habog valamit, vagy előáll valamilyen fél lábon álló teó- 
riával, melynek következtében tudatlan egyénünk tudatlansá- 
ga csöppet sem enyhül. E teóriákból én is hallottam már pá- 
rat. Az első az volt, hogy a digitális aláírás a digitális adathal- 
mazt feldolgozó és digitális eredményt adó algoritmusokkal 
összefüggésben értelmezett (mint amilyenek a nyilvános kul- 
csú eljárások), míg az elektronikus aláírás egy általánosabb 
fogalom, ami értelmezhető bármilyen a jövőben megjelenő 
elektronikus eljárásra, mely a digitális aláíráshoz hasonló biz- 
tonságot garantál. Azáltal pedig, hogy az EU irányelv és a 
nemzeti jogszabályok az elektronikus aláírás fogalmát hasz- 
nálják, egy általánosabb szabályozást biztosítanak. Ennek kö- 
szönhetően, ha — mondjuk — 2011-ben megjelenik egy, — te- 
szem azt — analóg adatokat feldolgozó analóg elektronikus 
aláírási eljárás, akkor majd nem kell újraszabni a jogszabá- 
lyokat. Nem tudom mennyi volt igaz ebből az okoskodásból, 
én mérsékelten hittem neki mindaddig, míg nem hallottam 
újabbat. 

Aztán jött az, hogy az elektronikus aláírás fogalmába tulaj- 
donképpen belefér az is, ha a word doksi végére gépelem a 
nevem. Vagy ha odaillesztem beszkennelt kézi aláírásomat. 
Na erre se gondoltam korábban, de tény, hogy ezek is elekt- 
ronikus úton készülnek, így miért ne nevezhetnénk őket 
elektronikus aláírásnak? Még jó, hogy ott volt talonban a di- 
gitális aláírás fogalma, s így ezek után mondhattuk azt, hogy 
a digitális aláírás az az elektronikus aláírás, ami nem tartozik 
ebbe a vicc kategóriába. 

Vagyis a nyilvános kulcsú kriptográfián alapuló elektronikus 
aláírás ebben az értelemben is digitális aláírás. Eme értelme- 
zés nem sokban tér el az előzőtől: e szerint is mondhatjuk 
azt, hogy a digitális aláírás az elektronikus aláírás részhalma- 
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za. Ugyanakkor e második értelmezés szerint ez a részhal- 
maz erősebb (nagyobb biztonságot garantál) mint az elektro- 
nikus aláírás nagy halmaza, míg az előző értelmezés szerint 
mindkettő ugyanolyan biztonságot garantált. 

A jogi terminológia ugyanakkor a digitális aláírás fogalmát 
nem használja, ő a hitelesség, sértetlenség és a letagadhatat- 
lanság követelményeinek nagy biztonsággal megfelelő elekt- 
ronikus aláírást , fokozott biztonságú elektronikus aláírás"- 
nak nevezi. 

Aztán szerencsére találkoztam ennél jobb elmélettel is. E sze- 
rint a digitális aláírás az a bitsorozat, ami kijön a nyilvános 
kulcsú algoritmusból. Ez önmagában nehezen értelmezhető: 
mellé kell rakni azt az információt, hogy milyen algoritmus- 
sal készült; azt hogy, kinek a nyilvános kulcsával ellenőrizhe- 
tő; hogy ez a kulcs (tanúsítvány) hol található; és így tovább 
számtalan értelmezési és kiegészítő adatot. Ezekkel az ada- 
tokkal együtt lesz a digitális aláírásból elektronikus aláírás. 
Nekem ez utóbbi magyarázat tetszik a legjobban, valószínű- 
leg újdonságértékénél fogva is. Egyik teória sem nyert azon- 
ban eddig olyan teret, ami segítségünkre lehetne a miheztar- 
tásban. A különböző programokban tipikusan digitális 
aláírásnak van magyarítva az eredetiben digital signature ki- 
fejezés. Mivel e programok legtöbbjét az USA-ban készítik, 
nem is várhatunk mást. 

A kifinomult európaiak ennél sokkal jobban tudnak diszting- 
válni: az európai szoftverek, a jogszabályoknak, szabványok- 
nak és ajánlásoknak megfelelően inkább az electronic 
signature kifejezést használják, míg a digital signature fogal- 
mat a speciális esetekre tartják fenn. A jól megfigyelhető kul- 
turális szakadék mellett vagy ellenére a szakemberek leg- 
többször szinonimaként használják a két kifejezést. Magam is 
így teszek, s csak akkor figyelek oda ennél jobban, ha való- 
ban meg akarok különböztetni két, valamiért különböző dol- 
got. 

Az elektronikus aláírás feltétlen divatosabb, így annak, aki 
haladni akar a korral, ezt tudom javasolni. Konzervatívabb 
egyének maradhatnak nyugodtan a digitális aláírásnál is, ami 
egyfajta nemes tapasztalatot s ódivatúságot egyaránt sugall- 
hat. Annak pedig, aki egyszerűen csak el szeretne igazodni, 
mindössze azt tudom javasolni, hogy figyeljen a szövegkör- 
nyezetre (és használjon azt, amit akar — a szerk.) 


Almási János 
Almasi-Janos€odbrt.hu 
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He légy rendszergazda! 
Secondary Logon Service 


Mai ,férges" világunkban már nem engedhetjük meg 
magunknak, hogy rendszergazdaként bejelentkezve 


üg esG BILL ző 


Windows cannot find "idlist, :180:1884,", Make sure you typed the name correctly, and 


then try again. To search for a file, click the Start button, and then click Search, 





tengessük mindennapjainkat. Hisz egy vírus, vagy egy 
féreg pontosan annyit tehet, mint a ,hívója", vagy gazdaprocessze. Ha a ,hívó" rendszergazdai jogokkal rendelkezik, 
akkor a gonosz kód is. Ez ellen találták ki a Secondary Logon Service-t és a RunAs-t. Megpróbáltam lehetőleg 
minden funkciót elvégezni RunAs-zel. Sikerült, bár elég mélyen bele kellett ásni szegény operációs rendszerbe! Kínomban 
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még a NetSH parancsot is használtam. 


byuógyszeresdobozt 
Windows Server 2003 Resource Kit Tools 


Van másik? Van, de azért ez egyelőre nagyon más(ik). Per pillanat 
a ,do more with less" jelmondat szó szerint érvényesül az új gyári segéd- 
program gyűjteményének tekintetében. 


aJClxd 





Selectthe components you woud iike to inetatt 
7 EMt Server. Fdters and togs internet and protocol rate 


Websense - Az Internetfelügyelő 


Az internet adta korlátlan szabadság néha a munka rovására mehet, sőt a 
cég számítógépein tárolt adatok is veszélybe kerülhetnek, ha ellenőrizetlen 
a vállalati webforgalom. 


7 Hetvodk Agent - Submás and mansges netnork ame tor EM Server 
67 Páhey Sérvér - Soros and drelnbutes Websente confguraton 

7 ReaTime Analyzer - Capturos data and genetates reports för reak bme anaais 
[7 User Sermce - izanages Websense directory semce communcaton 

7 wegsense manager . Acopts Websense condguraton senge 


7 DC Agent identtes users transparent for Elk Server 


A DHLP rejtett szépségei — UI. 


Azt már korábban is láthattuk, hogy a DHCP szolgáltatás nem áll önmagá- 
ban, számos más komponenssel együttműködik. A DNS, az Active 








kesz izi 





Scope [10.0.0.0] MAL-W2000 Properties 


General] DNS. Advanced ] 
AssigniP addresses dynamically to clients of: 
C DHCP only 
C B00IP only 





Directory, az RRAS és a DHCP viszonyát már tisztáztuk. A címkiosztó szer- c Bot 
8 öz a : öles, ásás az áj [7 Lease duration for BOOTP clients ————————————— 
ver azonban egyéb funkciókkal is szorosan integrált, sőt néha saját maga G Úddlte 
tartalmazza ezeket az alkalmazásokat. Ezúttal a BOOTP, a MADCAP, a RIS ÚSGE (s, s Hklée 
és a DHCP közti összefüggéseket vizsgáljuk. o dgdPAádPA 
C Unlimited 
Wii ki ű ff wo it oh tév 4 7 Ág 1 1 


A hibák közötti 
idő 
(normál üzemidő) 


Helyre- 


Reagálási 
ő állítási idő 


A 
felfedezésig Javítási idő 


tartó idő 











cikket olvashattunk a Stratus 











Alia Észlelés Diagnózis Javítás Megoldás Helyreállítás Újhiba 


bekövetkezik 


A Tech.net magazin szeptemberi számában egy nagyon érdekes 


Szolgáltatáskiesés (down time) szolgáltatáskiesés — a százfejű szörny DA 
] 


cég ftServer megoldásáról, amely tése 


A hibák közötti teljes idő 99 ,99999-os rendelkezésre állást ígér. Sőt, nem csak ígéri, 
hanem be is tartja, hiszen a cég honlapján naponta 
újraszámolják a világon futó ftServerek összesített rendelkezésre állását, 


az pedig még ennél is jobb. Mindezt fürtszolgáltatás nélkül... 


00. oldal 

















szu 4. lá z CA Certificate Reguest 2] 
Tanúsítvánukiadók a [indotusban — szseeesereees 

ef. . . Computer Name: [rerver2003.falatrax2003.hu Bigwse. he 
Oualified Subordination — esne — [fsszzszsa Tr] EG a 
A Oualified Subordination (kb. ,minősített altanúsítványkiadók") fogalom Naaa zzák ek kzlálatszzálbei ssel tis b 
ú: kések ő e ejt a. tC Nw2kSmembet falatrax2003.hu, Falatrax Enterpítse Iszuer CAJ2] reg Jo a 
egy új eszköz- és eljáráscsomag fedőneve a Windows Server 2003 k ezek eses brtepése Ea És 
Enterprise Edition nyílt kulcsú szolgáltatásai között. Segítségével a tanúsít- a 
ványkiadók hierarchiájának ágaban szereplő altanúsítványkiadók működé- ok ke 
sét minden eddiginél finomabban testreszabhatjuk. e 
0. Oldal B 
s 





07. oldal 


Kistestvére születik az ADO.ET-nek 
XMLA és ADO MD .NET előzetes 


Az MS SOL Server 2000 egyik újdonsága volt, hogy támogatta a relációs adat- 
bázisaiban tárolt adatok elérését XML segítségével. Az ADO.NET-tel a relációs 
adatok és az XML fogalma még jobban összefonódott. De mi van az Analysis 
Serverben tárolt régi jó adatkockáinkkal és adatbányász modelljeinkkel? EI tud- 
juk-e érni őket a .NET, vagy XML segítségével? Ezt fogjuk most megvizsgálni. 


33. oldal 


AES 
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a következő kilenc oldalban. 


ket A jb. oldal 


USZOAC- Euro Sign 




















Találd el a felhasználó igényeit! 
Igényfelmérés, követelményanalízis 

Hiába vagyunk a piac legnagyszerűbb fejlesztői, hiába találjuk ki 

a leghatékonyabb algoritmusokat, hiába dolgozunk a legmodernebb 
technológiákkal, ha egy dolgot nem tartunk szem előtt: a fő cél 

az ügyfelek elégedettsége. 
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Reguláris kifejezések 
Szövegfeldolgozás elmélet és gyakorlat regexekkel 


A szövegekben keresés, egyes részek cseréje, kiemelése már az informatika 
kezdete óta foglalkoztatja a szakembereket. A regexek segítségével rendkívül 
kifejező módon tudunk részleteket megfogni egy hosszabb és nem szigorúan 
szabályos szövegből is. Ennek elméleti és gyakorlati kérdéseit boncolgatjuk 





" Secondary Logon Service / [JJ i 


Ne légy rendszergazda! 


Íe légy rendszergazda! 


EEKEESKESIRB Logon Service 


ai ,férges" világunkban már nem engedhetjük meg magunknak, hogy rendszergaz- 
daként fajl tengessük mindennapjainkat. Hisz egy vírus, vagy egy féreg pontosan annyit te- 
het, mint a ,hívója", vagy gazdaprocessze. Ha a ,hívó" rendszergazdai jogokkal rendelkezik, akkor a 
gonosz kód is. Ez ellen találták ki a Secondary Logon Service-t és a RunAs-t. Megpróbáltam lehetőleg 
minden funkciót elvégezni RunAs-zel. Sikerült, bár elég mélyen bele kellett ásni szegény operációs 


rendszerbe! Kínomban még a NetSH parancsot is használtam. 


Október közepén készült az a féregvírus, amely a Windows 
Messengert támadja meg annak nyitott TCP portja mentén. 
Egy ügyes Buffer Overrun támadással a gonosz hacker saját 
kódját futtatja le a mit sem sejtő Messengerrel. A féreg kódja 
annak nevében fut, aki a Messengert futtatja. 

Miért is van az, hogy egy gonosz kód (vírus vagy féreg) pontosan 
azokkal a jogosultságokkal fut, mint a gazdája? Ez a Windows 
processzindítási modelljének és az Access Tokennek köszönhe- 
tő. Megfigyelték, hogy az egy és oszthatatlan VVINWORD.EXE 
néha gyenge, mint a harmat (ha Mari néni futtatja, nem tud be- 
leírni a S/STEM32 könyvtárba), máskor pedig olyan erős, hogy 
bármire képes (a Rendszergazda által futtatva simán letörli a 
Windows bármelyik alkönyvtárát — ha abban nincs nyitott fájl). 


Az Access Token 


A különbség nyilvánvalóan nem a WINWORD.EXE-ben ma- 
gában rejtezik, hanem az adott futtatás körülményeiben. Ami- 
kor bejelentkezünk a Windowsba, a rendszer hozzánk rendel 
egy leírótáblázatot, amiben a következő adatok vannak: Ki va- 
gyok én? Mely csoportoknak vagyok tagja? Milyen rendszer- 
szintű jogosultságaim vannak? Valahogy így: 





Access Token 

Személyes SID 

Globális és univerzális csoport SID-ek 
Lokális csoportok SID-je 
Rendszerszintű jogosultságok 





E Az Access Token tartalma 


A SID-ekről szerintem mindnyájan tudjuk, hogy miféle szerze- 
tek, a rendszerszintű jogokra pedig mondok egy példát, hogy 
mindenki tudja, mire gondolok: Log On Locally. 

A bejelentkezés után elindul az Explorer.EXE, és hozzárende- 
lődik a mi Access Tokenünk. (Ettől lesz az Explorer is pont 
olyan erős, mint mi magunk.) Ezután valahányszor például 
fájlműveletet hajt végre az adott program, az operációs rend- 
szer összeveti az Access Token tartalmát az adott objektum 
(esetünkben fájl) jogosultságlistájával (Access Control List), 
ami felsorolja, hogy ki mit tehet az objektummal, valahogy így: 





. Access Control List 


SID 1 DENY Write 

SID 2 DENY Full Control 
SID 3 ALLOW Delete 
SID 4 ALLOW Create 


B Egy jogosultságlista (ACL) belülről — leegyszerűsítve 





Az Explorer.EXE akkor törölheti a kiszemelt fájlt, ha az Access 
Tokenben szerepel a SID 3 (melynek tulajdonosa törlési joggal 
rendelkezik), de nem szerepel a SID 2 (mert annak tulajdono- 
sa teljesen el van tiltva a fájltól). 


Az Acces Token öröklődése 


Később a felhasználó különböző alkalmazásokat indít, ame- 
lyek szintén az ő nevében futnak. Ennek az az oka, hogy a 
Start Menüből indított további alkalmazások gyermekei az 
Explorernek, ezért öröklik annak Access Tokenjét. Sőt, az 
örökség nemcsak apáról fiúra, hanem a teljes családfán végig- 
fut. Ha bejelentkezés után indítunk egy Command Promptot, 
az gyermeke lesz az Explorer.EXE-nek. Ezután a parancssorból 
indítva egy programot, az a Command Promptnak gyermeke, 
az Explorernek pedig unokája lesz, de az öröklődés miatt ő is 
pontosan ugyanazzal az Access Tokennel fog rendelkezni, 
mint a nagyapja. 

Ha a férgektől való félelmünkben sohasem jelentkezünk be 
rendszergazdaként, elvileg sohasem leszünk képesek ,erős" 
alkalmazások indítására, ezáltal fontos funkciók ellátására 
sem. Hacsak az öröklődési lánc megbontására nincs valami 
módszer. De van. A Windows 2000 megjelenése óta lehető- 
ség van arra, hogy bármilyen programot saját Access Tokennel 
bocsássunk útjára. Ezt a Secondary Logon Service nevű szol- 
gáltatás teszi lehetővé. 


Tea 
ff Services (Loca) 


uz the servee 


Supports fi, Started 
Deszrotion Él shel Hardware Det... Ptovidesmu. . Stárted 


Enabes startng processes under Srple tást Transfer... Transports... . Started 
alternate credentials, I thes sérvice ís b. sözérő 8 


f gedinás Más see (dlzssatt arró Mange au. Starteó 


lable, IF this service is disabled, Smart CardHelper — Enables su... 
vices that ezpketly dependonk — Éysmartiniőervee started 
JARRE EJ SNMP Service Indiudes a... Started 
EYSNMP Trap Servite —— Receives tr. 
KÉJ SOLSERVERAGENT 
EMJSSDP Discovery Ser... Enebles dit... 
gy system Event Notfíi... Tracks syst. 
Klysystem Restore Ser... Performs s... 


E A Secondary Logon Service teszi lehetővé az Access 
Token-váltást 


Ez a szolgáltatás alapértelmezésben települ, és el is indul, így 
nincs más dolgunk, mint megkeresni a felhasználói felületen 
azokat az elemeket, amelyek révén használni is tudjuk. Ha 


megcsiklandozzuk a rendszergazdai eszközöket az egér jobb 
gombjával a Start Menüben, némelyiken azonnal felbukkan a 
Run As... parancs. Vannak olyan eszközök is, amelyek viszont 
csak a SHIFT-jobbklikkre tárulkoznak fel. (Nem sikerült 
megállapítanom, hogy mi a különbség oka. Van olyan MMC- 
konzol, ami sima jobbklikkre is RunAs-zel reagál, de van olyan 
is, amelyik nem.) Az alábbi ábrán a Certification Authority 
eszközt próbálom más felhasználó nevében elindítani: 


BY Administration Tools Pack Help 


.) My Documents 





erat usa 





(9) My Recent Documents. ) [77 open 
5 Élj Custer Administrator ölt 
7 My Pictures 3 component services TESB! 
a With... 
n z B] Computer Management Open 
27 My Music et Pinto Start menu I 
ű £S Connection Manager Adrnit 
29 s SendTo ; 
sg My Computer 9 Data Sources (00BC) ! 
ta.) My Network Places ID OHcp Cut ! 
9 £ Copy ! 
E Distributed File System ] 
Eg Control Panel gi CreateShortcut 
ella DNS Delete ! 
ME Zesaeea I CI Event viewer Rename ! 








3 A Run As... menüponttal más felhasználó nevében in- 
díthatunk alkalmazásokat 


Az Administrative Tools menüpontban a létező rendszergaz- 
dai eszközöknek csak a töredékét találjuk meg, a többi nincs 
selőmelegítve", hanem be kell tölteni (snap-in) egy MMC kon- 
zolba. Ha szükságünk van egy ,erős", ámde üres MMC kon- 
zolra, a parancssori RunAs segítségével indíthatunk egyet. 
Rögtön mutatom a szintaxist, de nem MMC-t fogok indítani, 
hanem egy Command Promptot. Hogy miért? Mert az továb- 
bi gyermekeket tud szülni, és rájuk hagyományozza a saját, 
megváltoztatott Access Tokenjét! Így ha további rendszer- 
gazdai parancsokat kell kiadnunk, ez a parancssor visszavár 
minket! 


Az ,erős" Command Prompt 


Az alábbi parancs egy olyan CMD.EXE-t indít, amelyik az 
Administrator nevében, annak Access Tokenjével fut: 


runas /user:administrator cmd 


Az eredmény egy olyan parancsablak, aminek a tetejéről leol- 
vasható, hogy kinek a nevében fut: 


Microsoft Windo 
CC) Copyright 19 


IC: XNWYINDOWSN 


2 Az ,erős" Command Prompt ablaka (lásd az ablak fej- 
lécében!) 


Ha ebből az ablakból , szülünk" mondjuk MMC.EXE-t vagy 
akár WinMine.EXE-t, az Administratori erősségű lesz. 

Úgy tűnik, minden a kezünkben van ahhoz, hogy soha többé 
ne kelljen rendszergazdaként bejelentkeznünk. 





Stílusváltás! 


Tegyünk két fogadalmat: 

1. Mostantól a napi rutinfeladatok végzésére 
NEM a rendszergazdai fiókunkat fogjuk hasz- 
nálni! 

2. Ha egy program csak akkor működik rendesen, ha 
rendszergazdaként futtatjuk, akkor SEM jelentkezünk 
be így, hanem 

a. kinyomozzuk, mi a hiba oka (RegMon, FileMon) 
b. csak az adott programot futtatjuk RunAs-zel. 


Az első fogadalom betartását az alábbi Login Script is elősegí- 
ti, amely három másodperc után kijelentkezteti azt a felhasz- 
nálót, akihez hozzárendeltük. Aki nem érez magában elég lel- 
ki erőt az 1. fogadalom betartásához, adja be magának intra- 
vénásan ezt a Logon Scriptet: 





next 


Ennek az azonnali logoff scriptnek egyébként elég jelentős 
irodalma — alakult ki a  NetAcademia  Tudástárban 
(www.netacademia.net/tudastar), például kiderült, hogy 
Terminal Sessionben nem jól működik, mivel üres marad az 
OWMI kollekció. (Egyelőre nem tudni, miért...) 

Természetesen teljes stílusváltás csak akkor lehetséges, ha 
minden rendszergazdai funkciót el tudunk látni RunAs segít- 
ségével. A célom az, hogy ezt bebizonyítsam, még akkor is, 
ha néha teljesen lehetetlennek látszik a feladat. 


Az Explorer indítása RunAs-zel 


Ha fájlokat szeretnénk másolni, könyvtárakat létrehozni, vagy 
egyszerűen csak valamilyen dokumentumot megkeresni, a 
legkézenfekvőbb megoldás az Explorer.EXE használata. No- 
sza, elő a RunAs parancsot, vagy a korábban elindított , erős" 
Command Promptot, és indítsuk el! 





Explorer EKE 


Se kép, se hang. Nem indul. Valószínűleg bugos, mert ha in- 
dítás előtt kilőjük a felhasználó által indított Explorert (amitől 
persze leesik a képernyőről a Start menü is), akkor elindul. 
Másképpen is lehet magyarázni az Explorer.EXE szabotázsak- 
cióját: ha elindulna, gyakorlatilag feleslegessé tenné az eddi- 
gi óvintézkedéseinket, minthogy egy ,erős" Explorer egyenér- 
tékű lenne azzal, mint ha rendszergazdaként jelentkeznénk 
be. Tehát nem indul el, bár egy hibaüzenettel azért 
vígasztalhatna minket. 

Fáljok másolására ott vannak a belső DOS parancsok (COPY, 
MOVE), vagy ha feltétlenül egérmozdulatokkal szeretnénk el- 
végezni a feladatot, elindíthatjuk az Internet Explorert is 
(IExplore.EXE, a Program Files Mnternet Explorer könyvtárban ta- 
lálható), amit ha ráirányítunk a C:X , URL"-re, veszi a lapot, és 
átalakul Explorerré (csak az automatikus frissítést nem végzi el). 
Igen ám, de ha az Internet Explorert indítjuk rendszergazdai 
erősséggel, még nagyobb hibát követünk el, mintha a sima 
Explorert indítottuk volna, hiszen elég egy kis figyelmetlenség, 
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Ne légy rendszergazda! 


és máris egy ,erős" böngészővel mászkálunk a neten. 
Az eljárás tehát nagy önfegyelmet igényel. A legjobb, 
ha lemondunk a Windows beépített grafikus fájlkeze- 
lőiről és valami más eszközt használunk fájlkezelésre. 


Vezérlőpult hívása RunAs-zel 


Talán a legfontosabb feladat, hogy a Vezérlőpultot el tudjuk 
indítani rendszergazdai erősséggel. Ha ez nem sikerül, akár 
fel is adhatjuk a küzdelmet, mert nem leszünk képesek elvé- 
gezni a legelemibb feladatokat sem (pl. IP-cím átállítása). 
A SYSTEM32 könyvtárban kutatva feltűnik a CONTROL.EXE, 
amit ha felhasználóként futtatunk, valóban felhozza a Vezér- 
lőpultot, telistele sok szép ikonocskával. Ugyanakkor ha 
RunAs-zel, vagy éppen az ,erős" Command Promptunkból 
próbáljuk indítani — se kép, se hang! 
Ez is bugos? Nem, ő csak fél egyedül. Csak akkor hajlandó 
elindulni, ha vele együtt kézenfogva elindul egy Explorer.EXE 
is. (Ennek az az oka, hogy a Vezérlőpult sem más, mint egy 
Explorer-mappa.) 
Korábban azonban láttuk, hogy (akarva vagy akaratlanul) 
olyan Explorer.EXE-nk van, ami mindaddig nem hajlandó elin- 
dulni a Secondary Logon Service hatóköre alatt, amíg elődjét, 
a felhasználó által indított Explorert meg nem öljük. Testvér- 
gyilkosság. 
Tehát a Vezérlőpult elindításának lépései: 

1. Task Managerrel kilőjük az Explorer.EXE-t 

2. CONTROL.EXE 
Ez utóbbi lépés rendszergazdai erősséggel elindítja az Explo- 
rert (lesz újra Start Menü stb.), ezzel gyakorlatilag romba dön- 
ti eddigi erőfeszítéseink eredményeit — viszont elindul a Ve- 
zérlőpult is. 
Miután elvégeztük a kitűzött feladatot, ki kell lőni az erős Exp- 
lorert, és el kell ismét indítani Mari néni Explorerét. 
Ez így használhatatlan. És ha nem figyelünk oda, nem is mű- 
ködik. Ugyanis az ,erős" explorert csak egy ,erős" Task 
Manager tudja kilőni. 


nErős" Task Manager indítása 


Ha a hagyományos módszerek valamelyikével indítunk Task 
Managert (például CTRL--ALT--DEL, Feladatkezelő), egy 
,gyenge" példányhoz jutunk, ami csak azokat a feladatokat 
tudja bezárni és kilőni, amik maguk is gyengék. 

Indítsuk el azonban az ,erős" Command Promptból, és máris 
ki tudja lökni az ,erős" Explorert! 


"Taskmgr.EXE 
Egyedi Vezérlőpult ikonok futtatása 


Ha a Vezérlőpult makacsul ragaszkodik egy ,erős" Explorer 
jelenlétéhez, ne használjuk. Próbálkozzunk meg inkább az 
egyes Vezérlőpult-ikonok elindításával! Hiszen minden egyes 
ikon mögött egy önjáró, magában is futtatható programocska 
lakozik. (Egészen pontosan fogalmazva: nem magában fut, 
hanem a RunDLL32.EXE futtatja őket.) A Vezérlőpult progra- 
mocskái a SYSTEM32 könyvtárban találhatók, .CPL kiterjesz- 
téssel. Az alábbi táblázat összefoglalja, hogy melyik mire való: 


CPL neve KIEG Et ei 


access.cpl Kisegítő funkciók 

appwiz.cpl Programok telepítése varázsló 
desk.cpl Képernyőbeállítások 
hdwwiz.cpl Hardvertelepítő varázsló 


inetcpl.cpl Az Internet Explorer beállítópultja 
intl.cpl Területi beállítások 

joy.cpl Játékvezérlők 

main.cpl Egér és billentyűzet 

mmsys.cpl Multimédia 

ncpa.cpl Hálózati beállítások (Explorer-alapú!) 
nusrmgr.cpl Helyi felhasználók és csoportok 
odbccp32.cpl ODBC kapcsolatok 

powercíg.cpl Energiatakarékossági funkciók 
slcpappl.cpl Smart Link modemek 

sysdm.cpl A System ikon 

telephon.cpl Telefon és modem opciók 
timedate.cpl A rendszeróra beállítása 


Ha például új programot szeretnénk telepíteni, írjuk be az 
serős" Command Promptba, hogy 





És máris előttünk a programtelepítő-varázsló. A billentyűzet és 
egér ikon érdekes jószág, ugyanis ha csak magában indítjuk 
el, a MAIN.CPL mindig az egérbeállításokat mutatja meg. A 
billentyűzet eléréséhez indítsuk így: 





Magyar Windows XP-n pedig így kell elindítani: 
Main.cpl billentyűzet. [ 


És ezt most komolyan mondom. Kipróbáltam! A parancssori 
paramétere valóban , billentyűzet", hosszú ű-vel! 


IP-cím átállítása 

Akkor most lássuk a legfontosabb, leggyakrabban használt 
ikont, a hálózatokat! Szinte mindennapos feladat, hogy IP- 
címet, alapértelmezett átjárót, esetleg a DNS-kiszolgáló címét 


át kell állítanunk. Írjuk be az ,erős" Command Promptba ezt: 


Ncpa.cplcEnters 


Majd várjuk a hatást! De a hatás elmarad. Se kép, se hang! 

A rutinos RunAs-guru ilyenkor azonnal tudja, hogy itt megint 
az Explorer.EXE állja utunkat. És valóban! Ha kilőjük a fel- 
használó Explorerét, és kétszer (sic!) elindítjuk az ncpa.cpl-t, 
el is indulna rendben. 

Hogy miért kell kétszer elindítani? Mert az első indításnál ezt 
a barátságtalan üzenetet kapjuk: 


ÜLNEK ELT 


Windows cannot find "idlist, :180:1884,", Make sure you typed the name correctly, and 
then try again. To search for a file, click the Start button, and then click Search. 





E Kínlódunk az Explorer.EXE-vel 


Ennek természetesen semmi értelme, mindössze azért vágják 
a fejünkhöz, mert elhagytuk a járt utat a járatlanért. De nem 
maga Bill Gates mondta, hogy ezentúl jobban ügyeljünk a 
biztonságos üzemeltetésre? Ilyenkor az az érzésem támad, 
hogy én vagyok e földgolyón a legelső személy, aki megfogad- 
ta Bill szavait. Még a saját programozói sem tették ezt! 

Ami ennyire izzadságszagú, attól tartsuk távol magunkat. 
Hagyjuk a Vezérlőpultot, mert jól láthatóan rajtam kívül senki 
nem gondolja, hogy pont ezzel kellene IP-címet változtatni. 





Hanem akkor hogyan? 

Kézenfekvő elgondolásnak tűnik a Registry Editor használata, 
csak az a baj vele, hogy a regisztrációs adatbázisba közvetle- 
nül belefirkált IP-címeket csak újraindítás után veszi figyelem- 
be a rendszer. (Elegendő lenne a hálózati kapcsolatot letiltani 
és újra engedélyezni, de akkor ugyanott vagyunk, mint az 
előbb: az ncpa.cpl használatára lenne szükség.) 

Nincs esetleg valami parancssori eszköz a hálózati kártya 
beállításainak babrálására? De van! 


NetSH a megmentőnk 


A NetSH parancs legalább olyan összetett és sokrétű, mint az 
NSLookup, és használni is hasonlóképpen két üzemmódban 
lehet: 

HA Ha paraméterek nélkül indítjuk, interaktív üzemmód- 
ban indul, parancssorába további speciális parancsokat 
lehet begépelni 

IH Ha a megfelelő paraméterekkel indítjuk, minden kérde- 
zés nélkül lefut, és elvégzi a rábízott feladatot. 


A számtalan alparancs és alprogram közül nekünk az 
INTERFACE alatti IP kontextus SET (beállítási) parancskészle- 
tére lesz szükségünk. Gépeljük be: 


netsh interf 


A következő beállítóparancsok léteznek: 





Tehát IP-címet, alapértelemzett átjárót, DNS- és WINS- 
kiszolgáló címet lehet vele beállítani. Kérdezzük csak meg tő- 
le, hogyan kell például IP-címet változtatni: 





A több képernyőnyi válasz legalsó két sora két példát mutat a 
parancs használatára. Az első példa a Local Area Connection 
fedőnevű hálózati kártyát dinamikus IP-cím kérésére állítja be. 





Egy picit túl van tupírozva ez a parancs, bőven elég lenne 
ennyi: 


netsh 


Ugyanis a NetSH töredékekből is felismeri, mire gondoltunk. 
Szinte már mesterséges intelligencia van benne (nincs!), hisz 
a ,Local" alapján kitalálta, hogy a Local Area Connection ne- 
vű kapcsolatra gondoltunk, míg a DHCP kulcsszóból arra kö- 
vetkeztetett, hogy DHCP-üzemmódot szeretnénk beállítani, 
nem pedig formázni a C:N meghajtót, amire amúgy sem képes. 
Hogyan nézne ki az a parancs, ami a DNS-kiszolgáló címét is 
DHCP-forrásúra állítja? Így: 


netsh interface 


A második példa pedig kézi IP-címet állít be ugyanezen a kár- 
tyán: 





EZBEKETTT 














Nem említettem, de a NetSH természetesen le is 
tudja kérdezni a jelenlegi állapotot a Show pa- 
ranccsal: 

netsh interface ip show address 

A teljesség igényével felsorolom, mi mindent tud 
megmutatni a NetSH: 





Ezek kivesézésére jelen cikkben nem térek ki. 


MMC snap-inek 


Még egy igen jelentős rendszergazdai ,feladatgyűjtemény" 
van hátra, ez pedig az MMC snap-inek futtatása rendszergaz- 
dai jogkörrel. 

Mi sem egyszerűbb: indítsunk egy ,erős" MMC.EXE-t, és az 
összes snap-in erős lesz benne! 

Mi a helyzet azonban akkor, ha egy távoli gépen kell , erős 
emberként" kotorásznunk az MMC snap-innel? Ez csak abban 
az esetben vezet sikerre, ha a másik gépen is rendszergazdák 
vagyunk. Ha az Administrator felhasználó neve és jelszava 
megegyezik a távoli gépen azzal, ami a helyi címtárban van, 
nincs probléma. Szintén nem ütközünk falakba, ha az ,erős" 
Command Promptot egy tartományi rendszergazda nevében 
indítottuk, és a távoli gép is ugyanannak a tartománynak tag- 
ja, mint a mi számítógépünk. 

Ha azonban ezek a feltételek nem teljesülnek, az MMC- 
konzol csendben , lepattan" a távoli gépről, új név--jelszó pá- 
rost nem kér. Ismeretlen névi-jelszó esetén viszont bolond lesz 
minket beengedni a távoli gép egy Disk Managerrel vagy ha- 
sonló célszerszámmal. Ilyen esetekben az alábbi módszert ja- 
vasoljuk: 


Építsünk ki rendszergazdai kapcsolatot távoli gépekkel! 


Ha az ,erős" Command Promptból a helyes név-tjelszó birto- 
kában sikeresen rácsatlakozunk a távoli gép egyik adminiszt- 
rációs megosztására (C$, ADMINS$ stb.), ezzel léket ütünk a 
távoli gép páncélján (lesz egy rendszergazdai, ,erős" kapcso- 
latunk). Ezen a lyukon keresztül azután a legvadabb MMC 
snap-inek is beférnek, hogy ott munkát, vagy éppen mérhetet- 
len pusztítást végezzenek. A csatlakozás után a snap-in felvé- 
telekor bátran állítsuk át az eszköz fókuszát a távoli gépre, 
úgy, ahogy ezt az alábbi ábra például a Computer 
Management esetén mutatja: 


[ela ee nerzsutát 





Select the computer you want this snapin to manage. 
This snapán wil always manage: 
(7 Local computer: (the computer this console is running on) 


€C Another computer [Tt 





(7 fállogy the selected computer to be changed when launching Írom the command ie. This) 
(only appbes if you save the console. ] 


E MMC snap-in futtatása távoli gépen 


Ne felejtsük el bepipálni az alsó jelölőnégyzetet, különben ké- 
sőbb nem fog menni a távfelügyelet, amikor az elmentett 
MMC-konzolt (.MSC fájl) indítjuk RunAs-zel! 


Fóti Marcell 
marcellfenetacademia.net 
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Kit Tools 


DUÓGUSZEIESdODOZzt 


Windows Server 2003 Resource 


Van másik? Van, de azért ez egyelőre nagyon más(ik). Per pillanat a ,do more with less" jelmondat szó 


szerint érvényesül az új gyári segédprogram gyűjteményének tekintetében. 


Mennyi? Ennyi? 


Úgy ahogy eddig megszoktuk, jelenleg nincs Resource Kit a 
friss Windows szerver változathoz. Persze kezdeti, illetve át- 
meneti időszakban vagyunk, még sok minden változhat, de 
innen a lelátóról úgy tűnik, hogy ez a helyzet nem is biztos, 
hogy sokat fog változni. Jelenleg egy mindenki számára sza- 
badon letölthető (a TechNet-ben sincs más) 12,7 MB-os Win- 
dows Server 2003 Resource Kit Tools csomaggal rendelke- 
zünk [w200o3reskit] valamint a szintén letölthető Windows 
Server 2003 Deployment Kit-tel [w2003deplkit] és kész. A pa- 
píralapú változatról sincs túl sok biztos hír, csak annyi, hogy 
jövő év elejére talán kész lesz [(w2003rbook] a 6586 oldal, 
amely az előzőhöz hasonlóan hét fejezetből áll és — úgy, 
ahogy a többi Windows Server 2003 könyvnél - kék színű fu- 
turisztikus barkácsszerszámok uralják a borítót. 

Ezenkívül érdekes lehet még, hogy Mark Minasi tollából 
ugyanilyen . címmel szintén megjelent egy — könyv 
[minasireskit], ami persze biztos jó, de nem ugyanaz. Viszont 
ha kész lesz az ,igazi", akkor ezekből a könyvekből fog majd 
állni: 

Directory Services Guide 

Distributed Services Guide 

Internetworking Guide 

Networking Guide 

Server Management Guide 

Internet Information Services 6.0 Resource Guide 
Technical References. Provides the Registry Reference 
and the Performance Counters Reference for Windows 
Server 2003 


BBB BBB BHB 


Láthatóan sok változás ezekben sincs a Windows 2000 Server 
Resource Kithez képest, maximum a TCP/IP helyett megjelent 
a Directory Service Guide. Persze, ha úgy nézem, hogy magá- 
ba a termékbe is beintegráltak jópár (főleg parancssori), eddig 
csak más Resource Kit-ekben megforduló programocskát, meg 
aztán az IIS6-hoz is megjelent a különbejáratú Resource Kit 
(iisreskit], és ott a Group Policy Management Console vagy a 
Windows System Resource Manager és a többi pl. innen 
[w2003downloadl letölthető ingyenes és teljes értékű eszköz, 
akkor azért sokat javul a kép. Az ebben a kis csomagban lévő 
majdnem 140 alkalmazás harmada teljesen új, (ami tegyük a 
szívünkre a kezünket: nem is rossz arány a Windows 2000 
Server Resource Kithez képest) a többit újraírták, valamint a 
Trustworthy Computing keretein belüli biztonsági felülvizsgá- 
lat eredményeképpen is kivágtak jópár nem eléggé megfelelő 
alkalmazást, ami megintcsak nem baj, sőt. 


Néhány észrevétel 


Ha letöltöttük a csomagot (rktools.exe), előtte vethetünk egy 
gyors pillantást a telepítési feltételekre, és konstatálhatjuk, 
hogy a Windows XP változatai alatt is működnek az alkalma- 
zások (hiszen egy család ez), de ettől függetlenül jónéhány 
természetesen Windows 2000 alatt is gond nélkül megy, illet- 
ve hogy semmi extra igény nincs, 30 MB szabad hely és 
ennyi. A telepítés next-next-finish típusú, a ResKit pedig szé- 
pen beleilleszkedik az XP féle Help and Support Center szín 
és design világába, úgy ahogy az alábbi képen is látható. 







ELSES EBET EREZZE EZTET 





5 hááto Envotten 33) Crane Br ET tocsteinfonterte 


hátba 
9. 





Active Directory Load Balancing 
AT T $9mos Esamolan ( felotná Tesi B öné 










]  ESEZAEgDZETTEEZETTA 
! DD Oectregi et 
Do 










zi 
CK] 


E Színes, szagos, de azért kényelmes is az új felület 


Egyesült a súgó és maga az alkalmazáslista, mely utóbbiban 
17 kategória van (plusz az ábécé szerinti lista és a szószede0. 
Nagyon jó ötlet volt az eszközök almenüjének egységes kiala- 
kítása a jobb oldali ablakban (Overview, Remarks, Syntax, 
Examples, Related Tools), és az esetek nagy részében igen tar- 
talmasak is az almenük. Viszont melegen ajánlom az , Open 
Command Prompt" hivatkozásra való kattintás elkerülését, 
mert ennek eredményeként a legtöbb esetben (pl. a ".vbs 
szkripteknél) jónéhány WSH ablakot kell , leokézni" míg meg- 
kapjuk a parancssort, ugyanis az aktuális parancsot  , /?"-lel 
együtt nyitja meg, és ez ehhez a borzasztóan idegesítő fejle- 
ményhez vezet. 

Ráadásul nem is a program mappájába teszi a parancssor 
promptját, hanem változó helyekre. Ezért ha többször is pró- 
bálgatni akarjuk a Resource Kit programokat, inkább a Start 
menüben szereplő Windows Resorce Kit Tools/Command 
Shell parancsikont használjuk. 

De nézzük most már inkább a tartalmat, először az Active 
Directory Management Tools kategóriából. 





OueryAD.vbs 


A GUI mellett van lehetőségünk immár parancssorból is ke- 
resni a címtárban, akár konkrét felhasználóra, gépre, szerve- 
zeti egységre, terjesztési listára vagy akár egy sémaattribútum- 
ra is. A keresésben maszkolhatunk is, illetve megadhatjuk, 
hogy melyik GC-re szabadítjuk rá a szkriptet. Az alábbi példa 
az s-sel kezdődő felhasználók nevét listázza a SERVER1 nevű 
GC közreműködésével. 





cseript gueryad.vbs -u"s8""SE 


RcontrolAD.exe 


Egy távoli üzemeltetést megkönnyítő grafikus felületű segéd- 
programról van szó. Gyakorlatilag egy Remote Desktop kap- 
csolat (amely szerveroldalához a Windows Server 2003-ban 
már nem kell külön Terminal Servert telepíteni, csak engedé- 
lyezni a bejövő kapcsolatokat) amely az AD Users and 
Computers MMC-ből indul. Természestesen szükséges hozzá 
a Domain Admin jogkör is. 

A kicsomagolás és a telepítés után kiderül, hogy elég egy da- 
rab — a tartományba tartozó — XP-n vagy Windows Server 
2003-on feltelepíteni (sőt egy erdőn belül többször nem is le- 
het mert az AD Users and Computers MMC modulját fogja ki- 
bővíteni), viszont ezután az összes fent említett operációs 
rendszerű gépet lehet ilyen módon távvezérelni, az összes 
olyan (de csak szintén XP és W2K3) gépről, amelynek 
9osystemroot9Yo mappájába bemásoljuk a csomag rcontrol.exe 
nevű alkotóelemét. 
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5 A távwvezérelhető gép helyi menüje kibővül 


Sonar.exe 


Hangzatos neve hasonlóan kellemes és új programot takar 
(prózaibb neve is van persze: FRS Status Viewer). A repliká- 
ciós forgalom és a forgalmat prezentáló gépek ellenőrzésére, 
naplózására, replikációval kapcsolatos alapos statisztikák ké- 
szítésére használhatjuk. Egy multimaster replikációs modellt 
megvalósító címtárban (ilyen a w2k és w2k3 alapú címtár) a 
replikáció alapfontosságú és megkerülhetetlen, az adathozzá- 
férés, a hibatűrés, terheléselosztás vagy a sebesség miatt 
egyaránt, telephelyen belül vagy kívül is. 

Szerencsére a replikációs folyamatok nagy része teljesen au- 
tomatikus és minimális beavatkozást vagy optimalizálást igé- 
nyel, de az ellenőrzésre és a hibakeresésre azért esetenként 
szükség lehet. Erre a célra szolgál ez a program. Természete- 
sen a DC-kre célszerű telepíteni, de lehet XP vagy akár Win- 
dows 2000 Professional kliensről is használni a programot. 
Ami mindenképp szükséges, az a Microsoft .NET Framework 
valamelyik — verziója. Ha viszont "Windows 2000 


ech.net Wa TrT$FI ág wo it h 


Professionalen futtatjuk és a Windows 2000 ) 
replikációt vennénk . 


Serverekkel kapcsolatos 
szemügyre, akkor szükség lesz még a Ntírsapi.di! ál- 
lományra is a DC 9Yosystemroot9oNsystem32 mappá- 

jában. A program indítása után egy beállítópanelt 

kapunk, ahol a tartományt, a replikakészletet, és a frissítési 
időközt kell megjelölnünk vagy elfogadnunk a felajánlottakat. 
Rögtön megtekinthetjük az aktuális állapotot vagy akár be is 
tölthetünk egy már korábban lementett lekérdezést. Ezután 
jön a program fő ablaka, melyben táblázatos formában a rep- 
likációban résztvevő szerverek típusát vagy állapotának jel- 
lemzőit soronként illetve oszloponként (és nagyon részlete- 
sen) tudjuk megjeleníteni. 


TESTES ETTTTETZETZNTT ETETETT TAT 





Szzeeede ACTIVE Running 


[omega Detut-Fest esc.hú ok o o o 
68 Detödt-Festeschu —— Suceede ACTIVE Running Ok 1 o o 
BE ——] zi 





[dead 0 [Penny 0 [fuccsedot 2 [Falod 0 [fierezhin 000023 [totty Ott (Log Stopped 7] 
a Az alsó géppel van egy kis probléma még... 


Ha a Disk and Data Management Tools-ban kutakodunk to- 
vább, szembetűnik két eszköz, amelyeknél sokkal komple- 
xebb és elterjedtebb megoldások is léteznek adatmentés té- 
makörben, de egyszerűségük akár kulcsfontosságú is lehet. 
Ezek a CD illetve DVD író programok parancssorból: a 
cdburn.exe és a dvdburn.exe. Mindkettő csak image-t tud irni 
(".iso), de mindkettő használható lemeztörlésre is. 


VolRest.exe 


Az előzőeknél valószínűleg lényegesen többet használt esz- 
köz lesz a Volrest.exe (Shadow Copies for Shared Folders 
Restore Tool), amellyel a szerver megosztott mappáiban ár- 
nyékmásolatokat tudunk keresni, illetve vissza tudjuk állítani 
a törölt vagy felülírt állományok előző verzióit (parancssor- 
ból). Miután egyszer már gondosan beállítottuk ezt a szolgál- 
tatást (jól odafigyelve szabad lemezterületre és az időzítésre), 
első körben keresünk a megosztásban: 





Az adott megosztásban árnyékmásolatokat keresünk tehát, 
méghozzá mappákat (/ad), rendszerállományokat (/a5), és rej- 
tett (/ah) állományokat is. Ha nem használjuk ezeket a kap- 
csolókat, ez utóbbi objektumok az alapértelmezés szerint szé- 
pen kimaradnak a keresésből. 





ett Viu2zk3Yconnon work /s 
OLI - Previous Version command-line tool 
(e) fsowriákt 2063 Microsoft Corp. 


Searching previous versions on Vw2k3tcommon work 
9/09/2003. 07:57 du. 278 Wn2kgNXcommon. workVEGMT-2803 . 09 .09-17 
0979/2009 07-55 du. 255 Wuzk3tcomnon morkNAeBGMT-2803.09 09-17 
5709/2803 07:50 du. 245 Ww2zk3tcomnon. work VEGMT-2803 . 09 09-17 
joc 
í heti 778 bytes 
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ús Az itt most nem használt /b kapcsolóval egy egysze- 


rűsített formátumú eredményt kapnánk. 

Látható, hogy három változat is van ebben a 
megosztásban a példa agenda.doc fájlból, két mó- 
dosított és egy törölt (ez már nem látható, ezt csak 


úgy mondom). Ezután, hátradőlve, láblógatva, kávéval a ke- 
zünkben visszaállítunk. Jelen esetben szeretnénk mindent, és 
természetesen célszerűen mindig egy másik mappába (mert 
jelenleg is ugyanitt lehetne az állomány egy későbbi verziója 
ugyanilyen névvel). 





Amennyiben a /e kapcsolót is használnánk, az üres mappák is 
visszaállításra kerülnének. Jelen helyzetben — mivel több azo- 
nos állománynév is van —, egy újabb dilemma lép fel, érthető 
módon valahogyan át kell nevezni a visszaállított objektumo- 
kat. Ez alapesetben zárójeles sorszámozással oldódik meg, ezt 
a következő ábrán lehet követni. 








erti ViuzkgYcommon work /r:c:Ytenp 
LREST 1.1 - Previous Version comnand- erira tool 
(0) tepve 2003 Microsoft Corp 


Restoring previous versions fron VWwu2zk3Ncommon work to c:Atemp 
9/09/2003. 07:57 du. 
409/2003. 07:55 du 
9/09/2003..87:50 du 


3 File(s) 778 bytes 


278 c:Memplagenda , doc 
255 c:MenpNagendat 1) . doc 
245 c:MempVagenda(2) . doc 


Ve 





B A visszaállítás boldog pillanatai 


Ha ugyanezt a parancsot így adjuk ki: 





akkor az árnyékmásolat időbélyege kerül az állománynévbe, 
egyszerűsítve a sorrendiség kiderítését. 





:Nvolrest Wazkgycomngn. mork /r:c:Wtemp /sct 
LREST 1.1 - Previous Version comnand-line tool 
(e) Copyright 2003 Microsoft Corp 


Restoring previous versions from VWs2zk3gtcommon work to c-Menp 

09/09/2009. 07:57 du. 278 c:MenmpVagenda (kedd. szeptember 09. 
8) doc 

09/09/2003.07:55 du. 255 c:WVWtemptagenda (kedd. szeptember 09, 


loc 
Jjrkágál 07:50 du. 245 c:NtempVagenda (kedd, szeptember 09, 
DP) .doc 


3 File(s) 778 bytes 
xv 





B A visszaállítás még boldogabb pillanatai 


Ha többféle állománytípusunk lenne, maszkolhatnánk is asze- 
rint, hogy mely típusokat szeretnénk visszaállítani. 


Ehhez a témakörhöz tartozik még a VolPerf.exe (Shadow 
Copy Performance Counters) amely telepítése után lehetsé- 
gessé válik az árnyékmásolatokkal kapcsolatos csokornyi 
mennyiségű teljesítményszámláló használata. Ami azért jó 
dolog, mert grafikusan ábrázolva kissé átláthatóbb lesz na- 
gyobb mennyiség árnyékmásolat esetén az üzemeltetés, mint 
az erre a célra szolgáló, beépített Vssadmin.exe nevű parancs- 
sori alkalmazással. 





Admx.exe 


Áttértünk a Group Policy Management Tools csoportra, ahol 
ez a segédprogram (ADM File Parser a becsületes neve) 
hasznos űrt tölt be. Két sablonállományt tudunk vele összeha- 
sonlítani, valamint egy tetszőleges sablonállományt tudunk 
szövegállományba lementeni. De nem ám a sima Export List, 
mint a Csoportházirend MMC-ben (amely gyakorlatilag a he- 
lyi menüben csak a helyet foglalja), hanem ténylegesen, kul- 
csokkal, beállításokkal, akár magyarázatokkal együttes expor- 
tot jelent. Nyilván nem helyettesíti, hanem kiegészíti a GPMC 
(Group Policy Management Console) nagyszerű lehetőségeit, 
mert hiszen ott is csak import van. Abban az esetben is jól jö- 
het a program, ha saját sablont gyártunk, hiszen egy kiexpor- 
tált gyári sablon mintaként szolgálhat. 


Ebben a csoportban összefuthatunk még az Inetesc.adm sab- 
lonnal is, ami az alapból igen szigorú IE Enhanced Security 
Configuration központi beállítását segíti elő. 


WinPolicies.exe 


Policy Spy néven is emlegeti a ResKit ezt a szintén új és felet- 
tébb hasznos segédprogramot, amely sok praktikus funkciót 
fog össze egy csokorba. Komplexitiását az is mutatja, hogy kü- 
lön súgója van (winpolicies.chm) és használható Windows 
2000 operációs rendszereken is. Meglátásom szerint annak 
lesz igazán praktikus, aki tesztelni vagy megjavítani szeretné 
a Csoportházirendet, vagy esetleg kipróbálni a lehetőségeit, 
mert olyan ellenőrző funkciói vannak, mint pl. a Tálcába 
beépülés és automatikus üzenetek megjelenítése házirend 
változás esetén (File/Notifiy when policy applied). Külön me- 
nüje van a házirendírissítéseknek (Refresh Policies) ahol a 
Windows 2000 esetén szükséges secedit, vagy az XP/Win- 
dows 2003-hoz passzoló gpupdate parancs is kiadható. Van 
egy bőséges hibakeresési menüje is (érdekes módon Trouble 
Shooting-nak hívják, így külön), ahol az érintőleges naplóállo- 
mányokat nyithatjuk meg, vagy akár mi is indíthatunk egy új 
naplóállományt, mondjuk egy házirendmódosítás kipróbálása 
miatt. 
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Frissítési időközök dumpja a registryből 


Lehetőségünk van hosszas turkálás helyett egy kattintással a 
registryből kinyerni a lényeges kulcsok tartalmát, pl. a frissíté- 
si időközöket, vagy akár a különböző házirendágak módosítá- 
sának történetét (Dump Machine History, Dump User 
History). Kérhetünk egy listát a rendszerben lévő összes fel- 








hnet 





használó/csoport SID-jéről a manuális ellenőrzéshez és még 
sorolhatnám az apró kis finomságokat. Ami kissé furcsa volt - 
és le sem tudtam tesztelni ezért - az az, hogy nem derült ki, 
mit takar vajon a gyakorlatban a Verify All Policies funkció. 
Mert azt ugyan már a menüpontban közli, hogy ez egy hosszú 
folyamat, de azt nem, hogy ehhez 5-ből 5 alkalommal a prog- 
ram szó nélküli bezárása szükséges O. 


EventCombMT.exe 


Az EventComb egy grafikus felületen működő eszköz, amely 
a tartományunkban lévő tartományvezérlők és tagkiszolgálók 
eseménynaplóiban tud széleskörűen keresni. Tökéletesen mű- 
ködik Windows 2000 alatt is. 

A program egyszerre több gép (mondjuk az összes DC, vagy 
az összes GC, stb.) naplóállományait is át tudja fésülni az ál- 
talunk beállított kritériumok alapján. A feltételek szűkíthetők 
naplótípusra (System, Security, FRS, stb.) valamint eseménytí- 
pusokra is (Error, Warning, Success Audit, stb.). Ezenkívül le- 
het konkrét eseményazonosítóra is keresni (vagy akár tól-ig 
módon, pl. 1000-1100-ig), és beállíthatjuk azt az időtartamot 
is (napban, órában, vagy percben), ameddig visszafelé figye- 
lembe veszi a naplóállományokat. Van lehetőség az esemény 
forrásának pontos definiálására (pl. atapi, LsaSrv vagy éppen 
Kerberos) és végül a korona: tetszőleges sztringre is kereshe- 
tünk. A keresés eredményét alapból a CNTemp mappába egy 
szövegállományba menti. 
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- Munkában az EventComb 


A trükkös rész 


Ha nem konkrétan keresek egy már korábbról ismert progra- 
mot, valószínűleg sosem vettem volna észre, hogy a felsorolt 
eszközökön kívül még létezik egypár a ResKit által , Individual 
Tool"-nak hívott programocska, jól elbújva. Ugyanis ezek az 
eszközök szerepelnek a közös mappában, de nincsenek kate- 
gorizálva és csak a Release Notesben van róluk szó. Nem tu- 
dom, miért van ez így, de a lényeg, hogy megvannak, mert 
van közöttük néhány igen hasznos alkalmazás. 


Acctinfo.dil 


Ha bemásoljuk a Yosystemroot?otsystem32 mappába és a kö- 
vetkező paranccsal beregisztráljuk ezt a dll-t, 


egy plusz fül (Additional Account Info) fog megje- —/ £) 


lenni minden felhasználó tulajdonságlapján az 
Active Directory Users and Computers MMC-ben. k 
Ez az új fül tartalmazza pl. a felhasználó legutóbbi 5 
jelszóváltoztatásának, a jelszó lejáratának vagy a 
legutóbbi be- és kilépésének az időpontját. 


Administrator Properties káli 


MemberOf ] Diakin ] Environment ] Sessions ] Remote control ] 
General ] Address ] Account ] Profle ] Telephones ] Organization ] 
Terminal Services Profle  ]/ COM: Additional Account Info 


PasswordLastSet — [2003.09.08. 1:32:27 Domain PW Info... ] 
Password Expires 12003.10.21. 0:19:58 
User Account Control [76048 Decode... I 


Locked: No 
Last-Logon-Timestamp: 2003.09.09. 8:26:14 


SID [8-1-5-21-2317353612:253533424-3048224253-500 SD Hi: ] íj 


GUID (83d90943-3856-4326-9a3c-429efab53951 





Properties On tau.insert.hu 
Last Logon [2003.03.09. 8:26:14 


Last Logoff [No value Set 
Last Bad Logon [No Value Set 
LogonCount [8 Bad Password Count. [ő 








OK ] Cancel I Épp 


E Egy pillantással is lehet sokat látni 





Tudnunk kell viszont, hogy ha több szerveren is használni sze- 
retnénk ezt a funkciót, akkor mindegyikre be kell másolnunk, 
illetve regisztráltatnunk az említett állományt. A fentiek mel- 
lett még jópár adat összegyűjthető a felhasználóról, de talán 
az ismerős dolgok mellett a User Account Control mező az 
ami az érdekes. Ez az érték felel meg az AD-ben beállítható 
olyan egyedi jellemzők számszerű összegének, mint pl. a kö- 
telező SmartCard használat a belépésnél, a fiókletiltás érvé- 
nye, vagy pl. az, hogy a jelszóváltoztatás engedélyezett-e 
(ezeket ugyenezen a panelen az Account fülön, az Account 
options-nál pipálgathatjuk be egyesével). Így aztán, ha valaki 
ezen a panelen kicsit gyakorol a Decode gomb segítségével, 
ránézésre meg tudja majd mondani hogy ha a 
userAccountControl értéke 512 vagy esetleg 8192642 akkor 
az milyen következményekkel jár felhasználóra nézve. 0 A 
panel jobb felső sarkában még egy hasznos dolgot vehetünk 
észre, ez pedig a Domain Password Policy információk. 


Domain Password Policy 





Max Password Age 42 2H:47M 
Min Password Age 01 0 H : 00 M 
Lockout Duration 00 0 H : 30 M 
Reset Bad PwW Count 000 : 00 H : 30 M- 


Max Bad Password Count Cannot Be Locked Üut. 
Previous Fws Kept 
Minimum Ftw Length 


24 passwordís) 
7 characterís) 
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Custreasonedit.exe 


Ugye mindenki lefagyott egy pillanatra, mikor elő- 
ször akart újraindítani vagy leállítani egy Windows 
Server 2003-at? Igen, én is azt gondolom, hogy a 
Shutdown Event Tracker elsőre meglepő volt, azóta 
idegesítő. Szerencsére van hozzá a Csoportházirendben op- 
ció, így le lehet tiltani a megjelenését. De ha mélyebben be- 
legondolunk, van azért értelme ennek az új szolgáltatásnak, 
különösen a szervereken. Hiszen távollétünkben is bekövet- 
kezhet újraindítás, amelyet nem biztos, hogy észreveszünk; 
vagy éppen elvárják tőlünk, hogy jelentést/statisztikát nyújt- 
sunk a leállásokról, illetve újraindításokról. Ezen feladatok 
megoldásában valószínűleg segít rajtunk ez a szolgáltatás, hi- 
szen egyrészt a nem kívánt újraindítások után rögvest feldob- 
ja az értesítő panelt az arra jogosult felhasználó belépésekor, 
illetve . szorgalmasan gyűjti a bejegyzéseket a 
9osystemrootyoNSystem3 2 ogfilesYShutdown mappában lévő 
XML állományba. 
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Network Connectivity - External Network Outage 
Network Connectivity - Local 

Network Connectivity - Reconfiguration 

Network Connectivity - Reconfiguration 

Network Connectívity - Troubleshoot 

other - Commission Server 

Other - Conserve Power 

jöther - Decommission Server 

Other - Power/Cooling Outage 

Other - Power/Cooling Outage 

Other - Previous Procedural ErrorfMisconfiguration 
Other - Prewionc Pracedural FrrariMisconfinuratinn 











E Szerkesztőmunka a helyi gépen (a Connecttel viszont 
más géphez is kapcsolódhatunk) 


Ha tényleg szükség van erre a szolgáltatásra, és nem elég- 
szünk meg az eredetileg definiált okokkal (amit a leállítás pa- 
nel listájában látunk), íme itt egy eszköz ennek a listának a 
testreszabására: a Custom Reason Editor. Beismerem, elsőre 
ez a bővítés/csere is elég perverz dolognak tűnik, de mégis, el- 
képzelhető, hogy nagyon jól jön ez a lehetőség. 

Az alkalmazás beüzemelése két lépésből áll. Először megke- 
ressük a Samplereasons.reg állományt a Windows Resource 
Kits Tools mappából, és hozzáadjuk a registryhez a tartalmát 


pl. egy dupla kattintással. Ezzel a régi leállítás listánkat telje- 
sen lecseréltük egy lényegesen bővebbre, amelyet még tovább 
szerkeszthetünk ezzel a parancssorból indítható, de a grafikus 
felületen működő alkalmazással, amelyet ezért célszerű . in- 
teraktív módban elindítani (a /i kapcsolóval). 

Az eszköz azért parancssorban is tud egy-két extrát, pl. ex- 
port/import funkcióval rendelkezik és a /L kapcsolóval indítva 
gyönyörűen kilistázza a már említett mappából a korábbi leál- 
lítással vagy újraindítással kapcsolatos eseményeket. 
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what do you want the computer to do? 


Shut down r] 


Ends your session and shuts down Windows so that you 
can safely turn off power. 


Shutdown Event Tracker 
Select the option that best describes vhy you want to 
shut down the computer 


Option: [7 Planned 


[munkaidő vége. :] 


Ilyet is lehet] 
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Íme az eredmény a megjelenésben 











Lockoutstatus.exe 


A végére maradt Account Lockout Status az előző eszközhöz 
hasonlóan egy hibrid képződmény: parancssorban kell elindí- 
tanunk de a GUI-n látjuk az eredményt. Ez az alkalmazás azo- 
kat a felhasználókat listázza ki, akiket a vonatkozó házirend 
alapján kizárt a rendszer. Nem szükséges több példányban te- 
lepítenünk a programot, mert a tartományon belüli összes tar- 
tományvezérlőről összegyűjti ezeket az információkat. A le- 
kérdezni kívánt felhasználóra hivatkoznunk kell a parancs- 
ban, pl. így: 


lockoutstatus /u:testdomaintgipszij 


A program az eredményben tételesen felsorolja a megvizsgált 
DC-ket, a kizárás tényét (ha ez a helyzet) és ezenkívül az el- 
rontott jelszavak számát is. 


Gál Tamás 
MCSE: Security 
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Hz Internetfelügyelő i 


Az internet adta korlátlan szabadság néha a munka rovására mehet, sőt a cég számítógépein tárolt ada- 
tok is veszélybe kerülhetnek, ha ellenőrizetlen a vállalati webforgalom. 


Ma már nem kérdés, hogy a vállalati számítógépeken szüksé- 
ges-e Internethozzáférés vagy sem. Számtalan elvégzett elem- 
zés, és kutatás kimutatta, hogy jóval hatékonyabb a munka- 
végzés, ha a dolgozó azonnal hozzáfér a világhálóhoz és a 
keresett adatot rövid időn belül eléri a saját gépén. A kérdés 
csak az, hogy a neten való keresgélés közben esetlegesen el- 
kalandozó figyelem nem hátráltatja-e a munkavégzést? A vá- 
lasz sajnos: De igen! 

A munka helyett file-cserélgető hálózaton MP3-at vadászó 
kolléga, illetve a legfrissebb játékokat, filmeket letöltő társa 
nem éppen tevékenyen járul hozzá a cég éves termelésé- 
hez. A vállalati vezetés szempontjából az elfoglalt, túlterhelt 
sávszélesség, illetve mostanában .a számítástechnikai bűn- 
esetek középpontjába került file-cserélgetős ügyek miatt jár- 
hat kellemetlen következményekkel az ellenőrizetlen web- 
forgalom. 

Éves jelentések készítésekor felmerülhet a kérdés: , Hogyan 
alakult az idén a vállalati Internetezés?" Vagy akár kérhetik 
tőlünk rendszergazdáktól, hogy statisztikai adatokkal indo- 
koljuk az Internet-elérés fejlesztésére elköltött pénz létjogo- 
sultságát. Mert ha a nem csekély összegért bekötött műhol- 
das kapcsolaton keresztül csak a filmletöltés lett gyorsabb, 
hamar lemondhatunk a cégvezetés jövőbeni támogatásáról... 


Visszatekintés — Hogyan volt? Mivé lett? 


Azt hiszem, minden kedves olvasóban él még az emlék, ami- 
kor , régen", a hazai hálózatok őskorában nagynéha véletlenül 
elérhető volt egy-egy gépen a csigalassúságú ,modemes" 
Internet. Nos, ott semmiféle védelemről, szűrésről, netán tűz- 
falról szó sem volt. Ez utóbbi fogalom is maximum az építé- 
szetben volt akkoriban ismerős. A gépek (igen nagy dolog volt 
a többes szám) mindegyike külső ,éles" IP címet kapott, és a 
cég hálózatából igencsak széles kapuk nyíltak a külvilágra. 
Drága volt és elérhetetlenül misztikus. 
valami borzongással vegyes áhítattal figyeltük a bennfentes 
kolléga billentyűkön zongorázó ujjait, amikor is az első ártat- 
lan statikus weboldal megjelent a villódzó képernyőn. Erről 
jut eszembe a régi számítástechnikus szóvicc is: 

— CGA monitor? 

- Nem, saját! 


Ugye milyen furcsa, de egyben kellemes érzés visszagondolni 
ezekre az időkre? Én ekkortájt döntöttem el, hogy ez lesz a 
szakmám. A rendszergazdai pozíciókban akkoriban dolgozó 
kivételes mérnökökre úgy gondoltam, mint ötévesen a pilóták- 
ra vagy mozdonyvezetőkre: Istenként tiszteltem őket. Az ős- 
korban, amikor a gépek, a hálózat és a teljes infrastruktúra tel- 
jesítménye a maihoz képest elenyésző volt is, jó érzés volt lát- 
ni a mi kis öreg gépünkön a , Világhálót" megtestesítő kezdet- 





leges oldalakat, és persze a folyton ott tevékenykedő, érthetet- 
len szavakat használó fura figurát: a rendszergazdát. 
Ki emlékszik például olyan fogalmakra mint Gopher, Finger, 
Usenet, Arpanet, Fidonet vagy Wais, MUD, MOO, Archie ne- 
tán BBS, Bitnet? Néhányról ma is hallani még, ám sokuk fele- 
désbe merült az idők folyamán. Ne 
felejtsük el viszont, hogy már a korai 
neten is lehetett információkat keres- 
ni, levelezni, olvasgatni — mai szem- 
mel nézve nevetségesen alacsony 
szinten, de lehetett! És ez volt a fon- 
tos: A lehetőség. Mert ennek a felis- 
merése indította el azt a folyamatot, 
ami mára megszülte ezen fogalmakat, 
hogy ,információs-szupersztráda" , 
meg ,információs-társadalom" , stb. 
ártó szándékú dolgot . De születtek egyéb új fogalmak is, 
mert ugye a jó és a rossz mindig 


Ha azt a bizonyos 
30-as számú téglát 
kivesszük a tűz 


falból, egy halom 


is beengedünk, kézenfogva járnak. Így lett: Vírus, Tró- 
j jai, Worm, SpyWare, Hacker, Cracker 
akaratlanul is... és még sokan mások, hogy csak egy 


párat említsek a sok közül, amitől 

szépen lombosodott az egykori kis 
fácska. Mostanra már elég nagy és terebélyes lett ahhoz, hogy 
a biztonságtechnika szükségszerűen szorosan összeforrjon a 
számítástechnikával. Ma már libabőrös lesz az összes hoz- 
záértő szakember attól a gondolattól, hogy a céges hálózatban 
levő gépek külső IP címeket kapjanak tűzfal nélkül. Állítom, 
hogy komolyabb károsodás nélkül maximum 10 percet mű- 
ködhetne így egy mai hálózat. Mert sajnos ott tartunk, hogy a 
károkozás is automatikus, mintha egy láthatatlan király egy 
géphadsereget vonultatna fel ellenünk és számítógépeink el- 
len. A megtámadott-legyőzött gép átáll az ellenséges csapatba 
és onnantól ő is az információk pusztításában vállal szerepet. 
Paradox módon ember alkotta valamennyiüket. 
Persze filozofálgatással nem sokra megyünk, cselekedni kell! 
Az első és legfontosabb lépés egy jó tűzfal és egy megfelelő 
tudással bíró hálózati szakember. Együtt szinte minden káros 
dolgot kívül tudnak tartani, védve a belső szeparált hálózatot. 
Ám a folyamatos, gyors munkavégzés biztosítása érdekében 
kénytelen-kelletlen neki is muszáj időről-időre lyukakat ütnie 
a tűzfalon. Ha az Internet — és ezen beül a World Wide Web 
— nyújtotta előnyöket beeresztjük a céges falak mögé, számol- 
nunk kell egyéb új, a biztonságot veszélyeztető tényezővel is. 
Ha azt a bizonyos 80-as számú téglát kivesszük a tűzfalból, 
egy halom ártó szándékú dolgot is beengedünk, akaratlanul is. 
Annyi mindent bele lehet csomagolni már a HTTP-be, hogy a 
lehetőségek száma végtelen, csak a programozók állhatatos- 
ságán és kitartásán múlik az egész. Jusson eszünkbe az 
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Exchange 2003 szerver és legújabb kliensének spe- 
ciális webes képessége, ami — ha szeretnénk — az 
RPC-t bújtatja bele a HTTP-be. Van tehát kiemelke- 
dően jó oldala is a webalapú fejlesztéseknek, de 
nemcsak a jó szándékú programozók , dolgoznak" a 
lehetséges újításokon. 


A megoldás: Websense 


Az előbbiekben ismertetett problémákra jó megoldást kínál a 
(websensel-es címen elérhető termék. Az átmenőforgalom 
alapú ellenőrzést megvalósító eszköz alkalmas a webforgalom 
szűrésére és a hozzáférések aprólékos szintű beállítására. 
Egyes oldalakat blokkolhatunk, illetve engedhetünk a legkü- 
lönfélébb szinteken: például az egész vállalati hálózaton, 
vagy csak egyes gépekre, vagy csak egyes userek-re, csopor- 
tokra nézve. Még időalapú korlátozás is lehetséges, azaz ami 
nem érhető el munkaidőben, munka után lehet nézegetni. 
Az alkalmazott módszer hasonlatos ahhoz, amiről egy koráb- 
bi cikkemben (tech.net 2003. augusztus: SPAM, anti-SPAM) a 
BrightMail által használt metódusról már írtam. A rendszer lé- 
nyege, hogy egy adatbázisban gyűlnek a gyártó cég által 
nemkívánatosnak mondott tartalmú oldalak, domain-ek és ezt 
az adatbázist használja, töltögeti szorgalmasan az általunk te- 
lepített Websense Enterprise. A Windows NT illetve W2k szer- 
ver alapú változat mellett létezik Sun Solaris és Linux operá- 
ciós rendszerhez készített verzió is. A Windows 2003 szerver- 
re fejlesztett változat a cikk születésének idején az ígéret stá- 
diumában állt. 


A Websense software-csomag 


A cég weboldaláról [websensel letöltve a demo verziót, a kö- 
vetkező opciókat választhatjuk önálló csomagokban: 
Websense Enterprise 

DC Agent 

Language Pack 

Network Agent 

Reporter 

Websense Explorer 

Websense Manager 


BBB BBBB 


Nagyon hamar kiderül, hogy egy igen összetett és bonyolult 
feladatokra felkészített termékkel állunk szemben. Első látásra 
ijesztőnek tűnhet a sok-sok funkció, beállítás. De ne kesered- 
jünk el, a második pillantásra is az. A fentebb felsorolt összete- 
vők együttes mérete 500 MB körül van és ezek még csak az 
install-anyagok! Telepítés után — a választott komponensek 
függvényében - ennél kevesebb hely is elég lehet, de az alkal- 
mazott szűrési módszerek tekintetében érdemes újragondolni a 
gép hardverelemeit. Memória szempontjából például már az 
installer is jelzi igényeit, hogy a későbbiekben ebből majd sok 
kell! 

Az Enterprise install eleve tartalmazza a felsorolt összetevők 
közül az önálló működéshez szükséges összes lényeges ele- 
met, és ezek egy általános telepítés után kb. 200 MB-ot fo- 
gyasztanak el a merevlemezről. Elsőre nekem kicsit zavaró 
volt, hogy külön-külön tölthetők le az egyes programrészek, 
mert azt hittem, hogy majd egyszerre kell mind a teljes műkö- 
déshez. Ez nem is áll távol a valóságtól, csak szerencsére az 
Enterprise-ban minden benne van, ami ténylegesen szüksé- 
ges. A többi csak azért érhető el külön, ha esetleg a funkció- 
kat elválasztva szeretnénk, több gépen elosztva telepíteni, 
vagy önmagában kipróbálni. 


A programcsomag teljes, mélyreható ismertetése túlmutat a 
cikk keretein, inkább csak kedvcsinálónak csemegézek a 
funkciók erdejében. Így a részletes termékismertetőtől is elte- 
kintenék most, hiszen ez elérhető a gyártó weboldalán. A 
Websense fő tevékenysége természetesen a Web-szűrés, az 
összes többi a kapcsolódó, kiegészítőktől zsúfolt bedolgozó, 
segítő modulok sokasága. Mint a felhasználói igényeket maxi- 
málisan figyelembevevő alkalmazás, a Websense is igazodik 
a már meglévő megoldásokhoz. Ha a vállalati hálózaton van 
már egy tűzfal — ez ugye nagyon valószínű -, vagy proxy eset- 
leg ISA szerver, a Websense képes ezekkel együttműködve vé- 
gezni feladatát. Az alábbi képen látható, hogy a legtöbb nap- 
jainkban használt hálózati technológiával képes összedolgozni. 
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hítp.fwwwwebsense.comlproductsíintegrationsííndex cím, Ifyour integration 
Partner is supported but not listed below, select"Universal Websense 
installation 

6 [Eheck PointTw) Firevvatt-1Rl 
€ Cisco(R) CscherContent Engine 
€ Cisco(R) PIXR) Firewall 

€ CiscoR) Routers 


€ Inktomk(R) -Caching Appllances powered by Trafic Server(R) 





Websense 
Enterprise 







€ Mictosof(R) internet Security and Acceleralion Server 
€ Microsoft) Proxy Server 

€C Network Appilance(TM) Net Cache(R) 

€ Universal Websense installation 
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2 A Websense együttműködési listája. 


Talán a képen nem jól látszik, de az installer felhívja a figyel- 
met, hogy az elérhető megoldás-szállítók felsorolása nem tel- 
jes, a többi gyártóhoz a további kompatibilitási lista a 
(webs integr] címen érhető el. Ahhoz, hogy a lehető legtöb- 
bet kihozzuk a program képességeiből, természetesen együtt 
kell működnie a címtárral. Erre a DC Agent nevű komponens 
segítségével képes. A védendő hálózat méreteitől, illetve az 
átmenő webes forgalom nagyságától és a már alkalmazott 
egyéb védelmi inírastruktúrától függően a modulokat szétvá- 
laszthatjuk, külön szerverekre tehetjük. A következő kép az 
Enterprise install részelemeit mutatja. 
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Websense 
Enterprise 


Select the components you would like to install. 

FF EIM Server - Fillers and logs intemet and protocol traffic, Í 
7 Nelwork Agent - Submits and manages network traffic for EIM Server. 

FF Policy Server - Stores and distributes Websense configuration. 

F7 Rea Time Analyzer - Captures data and generates reports for reattime analysis, 





[7 User Service - Manages Websense dírectory serice communication. 
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7 Websense Manager - Accepts Websense configuration settings. 


FF DC Agent- identífies users transparently for EIM Server. ! 


: új! 
ea Esze ! 
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E A Websense Enterprise és komponensei. 


Az egyik alprogram, a Real-Time Analyzer például igen 
hasznos, mert használatával naprakész reportokat készíthe- 
tünk. Ez persze nemcsak a vállalatvezetésnek jó, hanem saját 
magunknak is, amikor finomhangoljuk a beállításokat. Meg fo- 
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gunk ám lepődni, hogy mi minden jön be a hálózatra anélkül, 
hogy tudnánk róla. Ezt egy életszagú példával szemléltetném: 
Nálunk a hálózatban a hotbar.com domain felől érkezett egy 
ártatlannak tűnő kis Outlook kiegészítés. Az említett web- 
oldalra tévedve szinte azonnal települni akaró software az 
Outlook arculatát hivatott kissé , feldobni". Színes template- 
eket, gombokat, grafikákat helyezhetünk el vele a szokványos 
levelezésben. Kérdés, hogy ennek mi értelme van, azon kívül, 
hogy erősen erőforrásigényes az így születő felcicomázott 
levelek megjelenítése? Természetesen ezekre semmi szükség, 
de a legtöbb felhasználónak nagyon tetszik. 

Az ily módon feljavított" e-mailekben már ott hirdeti a prog- 
ram önmagát és egy link segítségével buzdítja a többi felhasz- 
nálót, hogy ők is lépjenek be az Outlookot lassító összetevők 
önkéntes telepítőinek népes táborába. Az arcátlanság csúcsa, 
hogy a weboldal még egy hamis Microsoft Authorized Partner 
logót is mutogat, a gyanakvóbb felhasználóknak. Egy futó 
Spyware detector jelezte, hogy az ártatlannak tűnő install s0- 
rán mi minden települt volna a gépre, ha hagyjuk: backdoor, 
remote information-collector, stb. Eme utóbbi eszköz tevé- 
kenységéről csak sejtéseim vannak, de még így sem szeret- 
ném, ha az Outlookban nekem ilyenem lenne... 

Nos, ez a , webfertőzés" és sok más társa simán elkerülhető a 
Websense alkalmazásával. A reportok elkészültével például 
igencsak szembeötlő lehet az összes gépről egy bizonyos 
irányba tartó hatalmas háttér-webtevékenység, amit a kis ártal- 
matlannak tűnő programocskák generálnak. Az említett példa 
csak egy a sok közül, aminek veszélyeire baráti elbeszélgetés 
során nem lehet a felhasználókat felkészíteni. Az ilyesmit kí- 
vül kell tartani a belső hálózatból. Láthatjuk, hogy ez a prob- 
lémakör tűzfallal csak nehezen kezelhető, hiszen állandóan 
változó, dinamikusan , fejlődő" web-es támadási módszerek 
jelennek meg napról-napra. Ha ezt állandó szabályrendszer- 
szerkesztéssel szeretnénk manuálisan elhárítani, igencsak sok 
dolgunk lesz. 

Ezért is képes a program az összes ismert, ,nagy" tűzfalgyártó 
termékével együttműködni. A következő képről az is kiderül, 
hogy a címtárak közül sem vagyunk pusztán az Active 
Directoryra ítélve, hanem más neves gyártók hasonló megol- 
dásaival is bátran kihasználhatjuk a Websense nyújtotta elő- 
nyöket. 
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E A Websense által ismert címtárfajták. 


A webes támadások többsége a felhasználók jóhiszeműségé- 
re, illetve a ,sok kicsi sokra megy" elvére alapozva próbálja 
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meg kicsikarni azt a bizonyos Yes-t a gép előtt ülők- 
ből. Gondolok itt az Explorerben időnként fel-fel- 
bukkanó kis figyelmeztető ablakokra, ahol nekünk 
kell kézzel engedélyezni vagy tiltani egy-egy oldal- 
ról érkező hasznos vagy káros programkódot. A vé- 
letlenül megtalált gonosz szándékú oldal kíséretében automa- 
tikusan felbukkant tíz-húsz popup ablakot zárogatva óhatat- 
lan, hogy az átlagos felhasználó itt-ott el ne fogadjon egy ké- 
tes tanúsítvánnyal rendelkező oldalt. 

Legrosszabb esetben az ablak alján található , Always trust" 
kezdetű mondat élén egy pipával egyetemben... Ezzel a prob- 
lémával szemben sem elég, ha kioktatjuk a felhasználókat az 
ilyenkor szokásos helyes tennivalókról. A potenciálisan veszé- 
lyes oldalakat egyszerűen ki kell zárni a hálózatból, kiküszö- 
bölve ezzel a véletlen károkozás esélyét is. 

A biztonságos web-elérés megvalósításán túl egyéb problé- 
mákkal is szembesülhetünk. Például rengeteg olyan kérdés 
merülhet fel a felsőbb IT vezetés felől, hogy meséljük csak el, 
hogy a dolgozók mit nézegettek a legtöbbet a cég számítógé- 
pein? Vagy az újonnan kifejlesztett méregdrága információs 
weboldal beváltotta-e a hozzá fűzött reményeket? Ilyen és eh- 
hez hasonló kérdésekre a forgalom figyelése és részletes nap- 
lózása nélkül biztosan nem tudunk érdemi választ adni. De ha 
van Websense, máris két legyet üthetünk egy csapásra. Egy 
eszközzel megoldható a többszintű központosított szabály- 
zás, naplózás, kiértékelés. 

Ha most újból visszagondolunk a régi időkre — mint ahogy azt 
a cikk során már egyszer megtettem — és összehasonlítjuk a 
pár évvel ezelőtti Internetezési szokásokat a maiakkal: ugye 
manapság már szükség van a nagyobb hálózatok 
webforgalmának kontrolljára? Mint ahogyan szükség van a 
tűzfalra is és a vírusvédelemre is. Ezek nélkül a mi feladataink 
megsokszorozódnának, elvéve az időt a hasznos munkától. 
Az ismertetett példánál maradva: nekünk kell majd odamenni 
a felhasználó gépéhez és kézzel leirtani róla a Hotbar által fel- 
telepített ártalmas programokat. De ilyen ám a Gator és a 
Kazaa is. Ha ezek ismeretlenül csengenek, látogassuk meg a 
Ispywarel címet. Végezetül megmutatnám a Websense 
Manager arcát, van itt minden, ami kellhet. Próbálják ki, hi- 
szen csak a káros weboldalakat veszíthetik vele. 
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. ADKHCLP rejtett szépségei — UI. 


Azt már korábban is láthattuk, hogy a DHCP szolgáltatás nem áll önmagában, szá- 


EE mos más komponenssel együttműködik. A DNS, az Active Directory, az RRAS és a 


DHCP viszonyát már tisztáztuk. A címkiosztó szerver azonban egyéb funkciókkal is 
szorosan integrált, sőt néha saját maga tartalmazza ezeket az alkalmazásokat. Ezúttal a BOOTP, a 








MADCAP, a RIS és a DHCP közti összefüggéseket vizsgáljuk. 





EZ 
a 
a 
ei BOOTP - a félig lenyelt előd 12 Computer Name 
e; A DHCP szolgáltatás nem volt előzmények nélküli, isteni fej- 15 Domain Name 
7 ből kipattant szikra. 1985-ben Bill Croft a Stanford egyetem- 17 Root Path 
0 ről és John Gilmore a Sun Microsystemtől készítettek egy 42 NTP Servers 
sz szabványtervet, amely RFC 951-es számmal és , Bootstrap 44 WINS Server 
í Protocol (BOOTP)" címmel vonult be a történelembe. Az ő 45 NetBIOS over TCP/IP Datagram 
szi megoldásuk sok tekintetben hasonlóan működött, mint a mai Distribution Server 
bzj DHCP kiszolgálók, bár nem pontosan ugyanúgy. Az eltérések 46 NetBIOS over TCP/IP Node Type 
e az alkotók indítékaiból, az előttük álló feladatokból fakadtak. 47 NetBIOS over TCP/IP Scope 
E A fenti két úriember a lemez nélküli munkaállomások elindu- 48 X Window System Font Server 
jő lási folyamatát szerette volna automatizálni. Így a BOOTP 49 X Window System Display 
s szabvány egy kétfázisú indítást definiált. (Az RFC az elsőt írta Manager 
g le részletesen.) 69 SMTP Server 
s Az első fázisban a munkaállomások UDP 67 (szerver) és UDP 70 POP3 Server 
a 68 (kliens) portokon keresztül kommunikálnak. A szerver egy 
vs IP címet biztosít a lemez nélküli gépnek, továbbá néhány pa- — A fenti lista lényegesen rövidebb, mint a DHCP opciók teljes 
gp ramétert, amelyet ők gyártói kiegészítéseknek (vendor táblázata, ráadásul néhány nagyon fontos paraméter is hiány- 
extensions) neveztek. Azt az információt, hogy a munkaállo- — zik. Nincs sehol szó bérletidőről (51-es opció) megújítási idő- 
más melyik kiszolgálóról, milyen nevű boot állományt tölthet ről (renewal time, 58-as opció, rebind time 59-es opció). Ezek 
le az induláshoz szintén a BOOTP kiszolgáló adja meg. Amá- — szerint egy BOOTP kliens nem újítja meg a bérletét? Nos, nem 
sodik fázisban a lemez nélküli rendszer TFTP protokollonke- újítja meg, mivel az IP cím kérését nem bérletviszonynak fog- 
resztül felveszi a kapcsolatot a korábban megadott szerverrel, — ja fel. S íme, ez a legnagyobb különbség egy DHCP és egy 
lemásolja a boot állományt, majd azt betöltve elindítja a — BOOTP ügyfél között. Egy BOOTP kliens kér ugyan IP címet 
szükséges operációs rendszert. a rendszerinduláskor, s minden újabb induláskor is, ám 
Tulajdonképpen az RFC szerzői oldották meg a tyúk-tojás — onnantól a címet saját magáénak érzi. Nincs további kapcso- 
problémát, amit mi korábban paradoxonként emlegettünk, — lata a BOOTP kiszolgálóval! Hogyan lehet így címeket kezel- 
vagyis ők javasolták a szórt üzenetek alkalmazását. Láthatjuk, —— ni? Hiszen az egyszer kiadott címről azután már nem rendel- 
hogy az első fázis igen-igen hasonlít a DHCP működési elvei-  kezhetünk, nem vonhatjuk vissza. ő 
hez. Központi címkezelésről van szó mindkét esetben, — A BOOTP világ másképp működik, mint a DHCP. A címek 
ugyanazokat az UDP kapukat használják a BOOTP és DHCP kiadása ugyanis a szabvány szerint egy táblázat alapján törté- 
kiszolgálók, kliensek, továbbá az üzenetváltásnál a csomag- — nik, amelyben előzőleg rögzítik a leendő ügyfél azonosító 
szerkezet is megegyezik, egy kivételtől eltekintve: a BOOTP — adatait, többek között a MAC címét is. Ha analógiát keresünk, 
csomagok csak 64 oktetnyi helyet biztosítanak a gyártói — a DHCP lefoglalt címeihez hasonlíthatjuk az eljárást — a bér- 
kiegészítéseknek, míg a DHCP 312 oktetet értelmez, amely- — letidőtől eltekintve. Vagyis szó sincs ellenőrizetlen folyama- 
ben a különböző opciók utaznak. (A két fogalom - opció és  tokról, épp ellenkezőleg. A BOOTP világ nem is kaphat címet 
gyártói kiegészítés - gyakorlatilag ugyanazt takarja.) olyan állomás, amelyről a rendszergazda nem tud. Kizárólag 
Ezek a hasonlóságok arra késztették a DHCP kiszolgálót meg- . a BOOTP táblázatba felvett hostok nyernek bebocsátást a há- 
alkotó programozókat, hogy lehetővé tegyék a BOOTP ügyfe- — lózatba. 
lek támogatását. A Microsoft a Windows NT 4.0 SP2 ótatá- . No persze ez nem is olyan kényelmes megoldás, mint a 
mogatja az idősebb testvér klienseit. DHCP, mivel előzetesen be kell gyűjteni legalább a MAC cí- 
A hasonlóságok mellett szólni kell a meglévő különbségekről  meket, a boot állományneveket, a TFTP szerver címeket, kéz- 
is. Jó kiindulási alap a szállítói kiegészítések felsorolása. zel frissíteni a táblát stb., stb. Mai szemmel nézve meglehető- 
sen fura, a szabvány megalkotásakor azonban még nem kel- 
lett naponta tucatjával telepíteni és kivonni gépeket a hálózat- 
1 Subnet Mask ból, vagyis a fenti megoldás is kielégítő volt. Arról nem beszél- 
3 Router ve, hogy a DHCP-hez képest a BOOTP világ még biztonságo- 
4 Time Server sabbnak is tekinthető, hiszen kizárólag a rendszergazdák exp- 
B Name Server licit engedélye után kaphat egy host címet, ami azért erőtelje- 
9 LPR Server sebb kontroll, mint egy scope aktiválása. A DHCP biztonságá- 
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ról azonban később még lesz szó, most nézzük, hogyan is fest 
a konkrét BOOTP implementáció. 

A Windows NT 4.0-ban a támogatás azt jelentette, hogy a 
szerver elfogadta a BOOTP csomagokat, majd a lefoglalt cí- 
meket (reserved addresses) kezdte el vizsgálni. Amennyiben 
talált olyan MAC-címet, amely a csomagban szereplő ügyfél- 
lel megegyezett, a bérletet kiosztotta. Amikor tehát korábban 
a lefoglalt címek működéséhez hasonlítottuk a BOOTP 
megoldásait, egyáltalán nem jártunk távol az igazságtól, mert 
a DHCP BOOTP ,emulációja" épp ezt a lehetőséget használ- 
ja ki. 

A Windows 2000-ben továbbfejlesztették a BOOTP támoga- 
tást, és a fenti megoldás megtartása mellett bevezették a ,,di- 
namikus BOOTP ügyfelek" fogalmát. Ez azt jelenti, hogy már 
nem kell a lefoglalt címek közé felvenni előre a BOOTP ügy- 
feleket, azok éppen úgy egy aktív bérlettartományból kapnak 
címet, mint a közönséges ügyfelek. Csupán két dologra kell fi- 
gyelni. A bérlettartomány tulajdonságai párbeszédpanelen az 
Advanced" lapon engedélyezni kell a BOOTP ügyfelek dina- 
mikus kiszolgálását, továbbá meg kell határozni, hogy mennyi 
időre kapják meg kiadott IP-címet. 


Scope [10.0.0.0] MAL-W2000 Properties 
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5 A BOOTP ügyfeleknek 30 napra szól az 
alapértelmezett bérlet 


A 30 napos bérletidő eléggé veszélyes dolog. Attól, hogy egy 
DHCP kiszolgáló DHCP ügyfélként szeretné kezelni a BOOTP 
klienseket, a szabvány még nem változik meg. Márpedig a 
BOOTP ügyfelek nem fogják megújítani a bérletüket. Ha tehát 
30 napon túl sem indítjuk újra őket, a DHCP kiszolgáló más- 
nak is kiadhatja a címüket. Bölcs rendszergazda tehát ezt az 
értéket legalább 100 napra, vagy még inkább 365 napra mó- 
dosítja. Manapság ugyanis a BOOTP ügyfelek eléggé sokáig 
képesek üzemelni egyhuzamban. A dinamikus támogatásnak 
van még egy fontos feltétele: az ügyfelek csak IP címet kérje- 
nek. Ha szükségük van a boot állomány nevére, TFTP szerver 
címére stb., akkor a dinamikus BOOTP ügyfél mint megoldás 
nem jöhet szóba. Valamilyen módon ugyanis hozzá kell ren- 
delni a fenti adatokat is a klienshez. Marad a korábban felvil- 
lantott ,reserved address" alapú megoldás. Felvesszük a 
BOOTP ügyfeleket a lefoglalt címek közé — megadva a MAC 
címét, nevét stb. és bejelölve, hogy BOOTP kérés érkezik 
majd. 

Ezután be kell állítani két speciális opciót, a 66 és 67 számút. 
Az első TFTP kiszolgáló nevét, a második a bootfájl nevét tar- 
talmazza. 
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Végül a szerver tulajdonságai lapon bekapcsolhatjuk 
a BOOTP tábla mappát. Ha ezt megtettük, lehetősé- 
günk van három adattal ellátni a BOOTP ügyfeleket. 
Az első és a harmadik már ismerős, itt azonban 
megadhatjuk még a teljes elérési utat is a boot állo- 
mányhoz. A klienshez felvett értékek alapján a tábla bejegy- 
zéshez egyértelműen hozzárendelhető a BOOTP ügyfél is. 
Ugye nem bonyolult? 

A Windows 2000 ennél tovább nem megy. A súgóban azt a fu- 
ra mondatot olvashatjuk, hogy a TFTP szervernek egy harma- 
dik gyártótól kell származnia, mert a Windows 2000 nem ren- 
delkezik ilyen kiszolgálóval. 
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Boot image file name: 


peter —— 


Full server path to boot image: 


pee ENSSANE 


IFTP file server: 


Etna 
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53 A BOOTP szabványt követő párbeszédpanel 
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A fenti állítás egy kicsit sántít, hiszen a RIS kiszolgálóhoz du- 
kál egy TFTP is. A pontos megfogalmazás tehát az lehetne, 
hogy a Windows 2000-et nem szállították olyan TFTP kiszol- 
gálóval, amely a BOOTP ügyfeleket is kiszolgálná. (Kár, hi- 
szen a PXE kliensek nagyon közeli rokonai a BOOTP-t hasz- 
náló állomásoknak.) 

A BOOTP szolgáltatásról összességében annyit mondhatunk, 
hogy a szabvány hű követése, ám nem teljes megoldás. 
Amennyiben azonban az IP-cím kiosztást tekintjük feladat- 
nak, úgy a DHCP kiszolgáló megfelelő támogatást nyújt a 
BOOTP ügyfeleknek is. 


MADCAP 


Ha a BOOTP szabvány a múlt, akkor a Multicast Address 
Dynamic Client Allocation Protocol (MADCAP) egy kicsit ta- 
lán a jövő. Nem azért, mintha a multicast szabvány nem len- 
ne legalább olyan idős, mint némely mai középiskolás (1986- 
ban jelent meg az RFC 988, amelyben először definiálták), ha- 
nem inkább azért, mert a rá épülő alkalmazások, mint a vi- 
deó-konferencia, azonnali üzenetküldés, e-learning megoldá- 
sok, stb. még csak most kezdik meg hódító útjukat. 

A MADCAP megértéséhez minimális szinten érteni kell a 
multicast világot is. Az már közismert, hogy a gépeknek egye- 
di IP címmel kell rendelkezniük, amelyek A, B, C osztályba 
sorolhatók, esetleg osztály nélküliek. Léteznek azonban D 
osztályú címek is, ezeket onnan lehet felismerni, hogy a IP 
cím első négy bitje 1110, vagyis egy multicast cím a 224.0.0.0 
és 239.255.255.255 tartományba esik. A multicast címekre a 
következő szabályok vonatkoznak: 
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1. Egy állomásnak rendelkeznie kell legalább egy unicast 
címmel, mielőtt egy multicast címet kap. 

2. Egy multicast címet több állomás is megkaphat — tulaj- 
donképpen ez az értelme. Egyedi címeknél ez tilos. A 
szabvány szerint az azonos multicast címmel rendelke- 
ző állomások halmazát nevezik multicast csoportnak, 
amelynek nulla vagy annál több tagja lehet. Egy cso- 
port nem csak egy logikai alhálózatból fogadhat tago- 
kat, és a hálózat tudja, hogy mely állomások tagok, és 
azok hol helyezkednek el. A csoport dinamikusan vál- 
tozhat. Bármely állomás bármikor csatlakozhat, vagy 
elhagyhatja a csoportot. (Ennél mélyebbre nem me- 
gyünk, habár a téma izgalmas.) 

3. Egy állomásnak több multicast címe is lehet egyidejű- 


leg. 


Tudni kell még, hogy bizonyos címek foglaltak, vagy speciális 
tulajdonságokkal bírnak. Néhány példa: 

1. A 224.0.0.0-224.0.0.255 címek csak a helyi alhálóza- 
ton érvényesek, az útválasztók semmiképp sem továb- 
bítják őket. 

2. A 239.0.0.0-239.255.255.255 címtartomány olyan al- 
kalmazások számára van fenntartva, amelyek elérhető- 
ségét (vagy inkább , sugárzási távolságát") szabályozni 
lehet. 

3. A fenti címtartományon belül a  239.192.0.0 
255.252.0.0 alhálózati maszkkal nagyjából hasonló 
szerepet játszik a multicast világban, mint a 10.0.0.0/8 
az unicast forgalomnál. Belső használatra ajánlott cím- 
tartomány, ideális a MADCAP kiszolgálók számára. Ez 
a címtartomány 262144 címet jelent, ami óriási szám, 
ha meggondoljuk, hogy egyetlen címet akár több ezer 
állomás is használhat. 
224.0.0.1 — minden állomás a helyi hálózaton. 
224.0.0.2 — minden útválasztó a helyi hálózaton 
224.0.0.5 — OSFPv2 útválasztók a hálózatban 
224.0.0.6 — OSFPv2 útválasztók a hálózatban 
224.0.0.9 — RIPv2 
224.0.1.1 — Network Time Protocol 
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A 224.0.1.0 -— 238.255.255.255 szabadon felhasználható 
multicast-ra épülő alkalmazások számára, legyenek akár az 
Interneten is. Persze a címeket ugyanúgy meg kell igényelni, 
de talán itt nincs olyan címéhség, mint az egyedi címek ese- 
tében. 

Fontos tisztázni, hogy a multicast címek függetlenek az egye- 
di IP azonosítóktól, tehát a MADCAP szerver sem függ a 
DHCP címtartományok meglététől. Ha egy kiszolgálón csak 
multicast bérlettartomány található, akkor azt MADCAP szer- 
vernek mondjuk. Ám később itt is éppúgy lehet , normális" 
scope-okat létrehozni, jól megférnek egymás mellett. 

Az sem szükséges, hogy az ügyfél unicast címe egy DHCP ki- 
szolgálótól származzon és fordítva: egy DHCP ügyfél nem 
csak a MADCAP által adott multicast címmel kapcsolódhat 
olyan csoporthoz, amely többi tagja viszont MADCAP ügyfél. 


A MADCAP kezelőfelülete 


Egy multicast címtartomány létrehozása épp olyan könnyű, 
mint egy közönséges bérlettartományé, sőt, ha lehet, még egy- 
szerűbb. A MADCAP kiszolgálók ugyanis szinte kizárólag 
címtartományokat definiálnak, opciókat azonban nem — 
ennyivel egyszerűbb az élet. 


A varázsló, amely a scope-ot létrehozza, csupán a címtarto- 
mány nevét, kezdő- és végcímét, a kizárt címeket és a bérlet- 
időt kérdezi meg. Mindezt azonban később is beállíthatjuk a 
scope tulajdonságai között, ahogy a következő ábra mutatja. 
A multicast címtartományokkal nem bánik olyan finnyásan a 
kiszolgáló. A tulajdonságok lapon könnyedén módosíthatjuk a 
kezdő és végső címet is, ha ez szükséges. 

Külön említést igényel a TTL érték. Az útválasztók számát je- 
lenti, amelyeken még áthaladhat a multicast forgalom. 
Ez egyszerűen szabályozza, hogy ,milyen messziről" érhető 
el az adott multicast alkalmazás (pl. egy e-learning tanfo- 
lyam). 
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2 Egyszerűen konfigurálható multicast címtartomány 


A multicast világnak van egy különös sajátossága, az illékony- 
ság. Egy videokonferencia záros időn belül véget ér, akárcsak 
egy tanfolyam, vagy egy élő közvetítés. A címeket hipp-hopp 
elhagyják a munkaállomások, sőt akár az egész címtartomány 
is feleslegessé válhat. A Windows 2000 készítői számoltak ez- 
zel a szituációval. A multicast bérlettartomány tulajdonságai 
között a második lapon beállíthatjuk, hogy a scope meddig él- 
jen, szakszóval: mikor járjon le. Ha eljött az idő, üt a scope 
órája. Elillan, mintha sohasem lett volna. 

Amilyen összetett és bonyolult tud lenni egy multicast forgal- 
mat lebonyolító hálózat, olyan egyszerű a MADCAP életre 
keltése — ez most kiderült. Egy valamit azonban érdemes fej- 
ben tartani: a MADCAP csupán egy eleme a hálózatnak, 
amely a fenti alkalmazásokat biztosítja. Szükséges, de nem 
elégséges feltétele multicast alkalmazások bevezetésének. 
Nem kerülhető el az útválasztók alapos felülvizsgálata és al- 
kalmassá tétele e speciális forgalom lebonyolítására. 


A DHCP és a RIS 


Még 2001 végén indult e lap hasábjain egy öt részből álló s0- 
rozat, amelynek keretében az Olvasó részletekbe menően 
megismerkedhetett a RIS, vagyis a Remote Installation 
Services rejtelmeivel. Most csak röviden szólunk a RIS és a 
DHCP kapcsolatáról. 





A RIS és a DHCP között néha , rejtélyes" kapcsolat van. Elő- 
ször is minden RIS szervert fel kell venni az Active Directory 
hitelesített DHCP kiszolgálóinak listájára. Vagyis a Windows 
2000 bizonyos szempontból a DHCP kiszolgálókhoz hason- 
lóan bánik az automatikus szoftverdisztribúciós feladatokat 
végző RIS szerverekkel. Miért is? A RIS kiszolgálók feladata a 
PXE ügyfelek kiszolgálása, s csodálatos módon a PXE ügyfelek 
DHCP csomagok segítségével kommunikálnak a RIS szerve- 
rekkel. Ezért szükséges a hitelesítés. 

Lássuk a tényleges forgalmat. Feltételezzük, hogy mind a 
DHCP, mind a RIS kiszolgáló az PXE klienssel azonos alháló- 
zatban van. 

1. A PXE ügyfél kibocsát egy DHCP-DISCOVER csoma- 
got, amelyben IP címet és PXE boot szerver címet kér. 

2. DHCP-OFFER csomag érkezik a DHCP kiszolgálótól 
egy IP címmel. 

3. DHCP-OFFER csomag érkezik a RIS kiszolgáló 
BINLSVC komponensétől a PXE szerver címmel. 

4. A PXE kliens DHCP-REGUEST csomagot küld a DHCP 
szervernek, IP címet kér. 

5. A DHCP kiszolgáló DHCP-ACK csomaggal nyugtázza 
a kérelmet. 

6. A PXE ügyfél egy újabb DHCP-DISCOVER csomagot 
bocsát ki. 

7. DHCP-OFFER csomag érkezik a DHCP kiszolgálótól az 
előző IP címmel. 

8. DHCP-OFFER csomag érkezik a RIS (BINLSVC) kiszol- 
gálótól a PXE szerver címmel. 

9. A PXE kliens DHCP-REGUEST csomagot küld a RIS 
szervernek, és a PXE boot szerver címét kéri. 

10. A RIS (BINLSVC) egy DHCP-ACK csomagot küld, 
amely a szerver IP címét, nevét, valamint annak az ál- 
lománynak a nevét tartalmazza, amelyet a TFTP kiszol- 
gálótól kell kérnie az ügyfélnek (Ez a startrom.com). 


Látható, hogy a harmadik és hetedik csomag felesleges. A har- 
madik csomagra sohasem fog válaszolni a PXE ügyfél, mert 
nem tartalmaz IP címet, míg a hetedik azért felesleges, mert IP 
címmel már rendelkezik a delikvens. Mindez azonban a szab- 
ványból következik. DHCP-OFFER csomagra minden DHCP 
kiszolgáló válaszol. (A BINLSVC konfigurálható ennél finnyá- 
sabb módon is. A RIS-nél beállítható, hogy csak az ismert ügy- 
feleknek válaszoljon. Ha a PXE ügyfél nem tud ismert GUID- 
ot felmutatni, a BINLSVC egyszerűen hallgat, nem küld vála- 
szokat.) 
Ha a RIS és a DHCP egy kiszolgálón dolgoznak, lényegesen 
egyszerűbb párbeszéd zajlik a szerver és az ügyfél között. 
Csupán az alábbi: 
1. DHCP-DISCOVER csomagot bocsát ki az ügyfél (IP cí- 
met és PXE boot szerver nevet keres). 
2. DHCP-OFFER csomagot küld a kiszolgáló IP-cím aján- 
lattal és PXE boot szerver névvel. 
3. DHCP-REGUEST kérés indul az ügyféltől a kiválasztott 
IP címmel. 
4. DHCP-ACK nyugtázza a cím kiadását. A csomag tartal- 
mazza az IP címet, a RIS szerver címét, és az első letöl- 
tendő állomány nevét. 


A trükk annyi, hogy a DHCP megkérdezi a BINLSVC szolgál- 
tatást, hogy kívánja-e hozzáadni a maga információit a DHCP 
csomagokhoz. A PXE kliens egyébként az utóbbi forgalmat 
szereti. Ha két DHCP kiszolgálótól is kap csomagot, akkor azt 
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fogja minden esetben preferálni, amelyik egyben RIS 
szerver is. A RIS kiszolgálók terheléselosztásánál ezt 
figyelembe kell venni. 

A fenti forgalomnál feltételeztük, hogy a három sze- 
replő (PXE ügyfél, DHCP és RIS kiszolgáló) egy alhá- 
lózaton működik. Az élet azonban lehet ennél bonyolultabb, 
megeshet, hogy akár az egyik, akár mindkét szerver egy má- 
sik alhálózaton dolgozik. Ekkor természetesen DHCP Relay 
Agentekre van szükség, amelyeknek több helyre is továbbíta- 
ni kell az elkapott DHCP-DISCOVER csomagot: a címkiszol- 
gálók mellett a RIS szervereknek is értesülnie kell a PXE ügy- 
fél indulásáról. 

A 0259670 cikk egy érdekes, de a Microsoft által nem támo- 
gatott eljárást ír le. Ennek lényege, hogy három opciót be kell 
állítani egy adott scope-hoz (ezek közül egyet netsh felületen 
keresztül), amelynek nyomán a DHCP kiszolgáló rögvest el- 
végzi a BINLSVC munkáját is, mert megadja a RIS szerver ne- 
vét, címét és a boot állomány nevét. A megoldás hátránya, 
hogy a RIS szervert a scope-hoz köti, ráadásul kicselezi a 
BINLSVC fent említett biztonsági mechanizmusát is. Viszont a 
megoldás teljesen hasonlatos egy BOOTP induláshoz. Mi kell 
egy BOOTP kliensnek? IP cím, TFTP szerver cím, boot fájl név. 
És mi kell egy PXE kliensnek? Ugyanez. Nohát, nohát. Akkor 
miért kellett megalkotni egy új szabványt, a PXE-t, ahelyett, 
hogy az öreg motoros BOOTP-t használták volna? 

A válasz nem triviális, de valamennyire érthető. A BOOTP egy 
kihalóban lévő szabvány, mára már alig használják, legfőkép- 
pen pedig nem dinamikus. A DHCP ugyan dinamikus, de 
alapértelmezetten nem tartalmaz olyan adatokat a kliensek- 
ről, amilyenek egy PXE hostnak szüksége van. (Láttuk, meg- 
oldható, de nem túl szerencsés). Kell tehát egy olyan szab- 
vány, amely IP címet oszt, TFTP szerver nevet és boot image 
elérhetőséget és dinamikus. Ilyen nem volt, ezért megalkották 
a PXE-t. 

Nem lehetett volna ezt a funkciót mégis a DHCP-be gyúrni? 
Talán lehetett volna, ki tudja. Az mindenesetre árulkodó, hogy 
a PXE nem egy RFC szabványon alapul, vagyis nem IETF alko- 
tás. Ki tudja? Egyszer talán összeolvasztják a két eljárást — 
olyan sok közös vonásuk van. Egyelőre azonban ez csak talál- 
gatás. Volt a BOOTP, van a DHCP és a PXE, nekünk pedig 
mindegyiket tudni kell alkalmazni a maga helyén. 


E. 


Lepenye Tamás, MCSE 2000 
lepenyetomal.hu 
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gzolgáltatáskiesés 7 
a százlejű szörny 


A Tech.net magazin szeptemberi számában egy nagyon érdekes cikket olvashattunk a Stratus cég 
ftServer megoldásáról, amely 99,99999-os rendelkezésre állást ígér. Sőt, nem csak ígéri, hanem be is 
tartja, hiszen a cég honlapján naponta újraszámolják a világon futó ftServerek összesített rendelkezésre 
állását, az pedig még ennél is jobb. Mindezt fürtszolgáltatás nélkül... 


Biztonság kontra rendelkezésre állás 


Az első kérdés, amely felötlött bennem, az volt: vajon 
mennyire biztonságosak a Stratus hardveren futó Windows 
2000 vagy Windows Server 2003 operációs rendszerek? Ha 
ugyanis valóban 99,99999-os a szerverek rendelkezésre állá- 
sa, akkor abba az évi öt percbe nem fér bele több, mint legfel- 
jebb egyetlen újraindítás. Mi hiszünk abban, hogy egy jól be- 
lőtt Windows 2000 akár évekig is futhat, de a gyakorlati ta- 
pasztalatunk sajnos az, hogy bármilyen jó is a rendszerünk, 
néha elkerülhetetlen az újraindítás — külső körülmények miatt. 
A szoftverfoltokra és a javítócsomagokra ugyanis szükség van. 
Maga a gyártó ajánlja a biztonsági patchek alkalmazását, a 
nagyobb javítócsomagok pedig gyakran kompatibilitási felté- 
telt jelentenek egy-egy alkalmazás futtatásához. 
Meglátogattam a Stratus honlapját, hogy van-e a speciális 
hardvermegoldásuk mellett még valami, amivel képesek fel- 
számolni a rendszerükben meglévő egyetlen Achilles-sarkot: a 
Windows 2000 újraindulási kényszerét. Kellemes meglepetés 
volt, hogy a fenti cikken kívül további, a rendelkezésre állást 
növelő szoftveres kiegészítőkről olvashattam. A [stratus sw] 
lapon a ,Hardened drivers", a ,Ouick dump", az 
sActiveServiceTM architecture" és még megannyi más, a cég 
által fejlesztett megoldásról esik szó, ám a szoftverfoltok új- 
raindítás nélküli alkalmazásáról nem láttam semmit. Ekkor rá- 
kerestem a Search gombbal a , patches" szóra, s lám, a harma- 
dik találat épp az volt, ami engem érdekelt [startus patch]. Ez 
pedig már világos beszéd: a Stratus a rendelkezésre állás nö- 
velése érdekében letesztel minden egyes kiadott Microsoft ja- 
vítófoltot, és kategorizálja azokat aszerint, hogy az általa 
elvégezett operációs rendszerbeli módosítások és a szoftver- 
folt együttes használata milyen kockázatokkal jár. (További 
részletek a weblapon.) Ugyanakkor az is világossá vált, hogy 
a teszten átment kódot pontosan ugyanúgy kell kezelni, mint 
egy normális frissítést. Ha a gyártó szerint újra kell indítani a 
gépet, akkor újra kell indítani, nincs mese. Ettől kezdve 
világos, hogy vagy nem igaz a sok kilences a weblapon, vagy 
nem kellően naprakészek a Stratus szervereken futó operációs 
rendszerek. Mivel a cég szavahihetőségében semmi okunk ké- 
telkedni, kizárásos alapon a második lehetőséget kell válasz- 
tanunk... Tényleg? 


Csigavér 

Akkor most egy álommal kevesebb? Oda a remény, hogy 
99,99995 rendelkezésre állást lehessen Windows platformon 
biztosítani? Felesleges volt a Stratus sok-sok innovatív fejlesz- 
tése? Vagy, ami még rosszabb: nem az teljesül, amit ígérnek? 


És egyáltalán, mi a Stratus kapcsolata például a fürtökkel? Ha 
az egyikbe belefektettem a pénzem, akkor a másikba már nem 
érdemes? Vagy mind a kettőre szükség van? 

Ahhoz, hogy ezekre a kérdésekre elfogulatlan és szakmailag 
helyes választ adjunk, azt kell tisztáznunk, mit is értünk ren- 
delkezésre állás alatt, miben különbözik ez attól, amit a gyár- 
tók értenek a fogalmon, és milyen eszközeink vannak a ren- 
delkezésre állás növelésére, vagy megfordítva: a szolgáltatás- 
kiesés elkerülésére. 


A rendelkezésre állás fogalma 


Nos, rendelkezésre állásról a vállalatok informatikusai általá- 
ban egy konkrét szolgáltatás esetén beszélnek, s annyit jelent, 
hogy az adott szolgáltatás (például SAP) a felhasználók szá- 
mára elérhető, rendeltetésszerűen használható, tehát rendel- 
kezésre áll. Mértéke 99, amely a szolgáltatás rendelkezésre ál- 
lásának aránya a teljes birtoklási időhöz képest. 

Nem nehéz belátni, hogy az SAP, amely egy (legfeljebb né- 
hány) NT service, csak akkor áll rendelkezésre, ha mindazon 
egyéb hardver és szoftver komponensek is működnek, ame- 
lyek közvetlenül vagy közvetve az alkalmazást szolgálják. 
Vagyis elérhetőnek kell lennie a felhasználó gépén kívül min- 
den aktív hálózati elemnek, amely az SAP kiszolgálót és az 
ügyfelet összeköti, az SAP alatt futó hardvernek, operációs 
rendszernek, adatbáziskezelőnek. Emellett működnie kell egy 
névfeloldási rendszernek, egy hitelesítési rendszernek (Active 
Directory), esetleg egy háttértároló rendszernek, és akkor még 
nem is beszéltünk olyan opcionális rendszerekről, mint a 
webkiszolgálók vagy a terminál szerverek. Ha pedig a végle- 
tekig szeretnénk kihegyezni a dolgot, még annak a nyomtató- 
nak a rendelkezésre állása is számít, amellyel egy szállítóleve- 
let nyomtatnak ki, hiszen ha nincs szállítólevél, állnak a ka- 
mionok, egyre hosszabb sorban, és teljesen mindegy, hogy 
működik-e az az átkozott SAP, ha nincs ,output", jelen eset- 
ben egy A4-es lap, amelyet a sofőr magával visz. 

Szóval ennek a borzalmasan bonyolult valaminek kell rendel- 
kezésre állnia — a vállalati informatikusok és végeredményben 
a felhasználók szemszögéből. Ha egy vagy több komponens 
nem működik, akkor egy vagy több folyamat, művelet, ,out- 
put" kiesik, hiányzik, eltűnik, — nem áll rendelkezésre. 


A fenti szörnyűség már önmagában sem jó hír, de van ennél 
még rosszabb is. Könnyen belátható, hogy egy rendszer teljes 
rendelkezésre állása az alrendszerek rendelkezésre állásának 
szorzata. Tegyük fel, hogy van egy webkiszolgálónk. Ha egy 
évben egyetlen alkalommal meghibásodik a kiszolgáló egyik 








alkatrésze (pl. hálózati kártya egy napra), akkor a hardver mint 
alrendszer rendelkezésre állása 364/365, vagyis 99,7299. Ha 
az operációs rendszer is meghibásodik egy napra, akkor an- 
nak a rendelkezésre állása is 99,729o. Csakhogy a teljes rend- 
szer két napot nem üzemelt, így a rendelkezésre állás már 
csak 994590. Axiómaként elfogadható, hogy egyetlen alrend- 
szer rendelkezésre állása sem érheti el az elméleti 10099-ot, 
vagyis minél több alrendszerből áll a teljes üzemeltetési kör- 
nyezetünk, a sok egynél kisebb szám szorzata egyre kisebb 
végeredményt jelent. A sok kilences hamar eltűnik, ha a teljes 
rendszerről beszélünk. 

Van tehát egy nagyon bonyolult rendszerünk, amely sok-sok 
alrendszerből, komponensből áll, ezért a teljes rendelkezésre 
állási mutatója erősen lefelé tendál, ugyanakkor vannak az üz- 
leti felhasználók, akik viszont egyre türelmetlenebbek bármi- 
féle kieséssel szemben. A jövőben várhatóan még sokkal bo- 
nyolultabbak lesznek az eszközeink és még türelmetlenebbek 
a felhasználók. Van kiút ebből a harapófogóból? Persze, hogy 
van, csak nem könnyű és nem mindig olcsó. 


A gyártók által hirdetett rendelkezésre állás 


A fenti rendelkezésre állás fogalom világos, és a gyártók által 
ajánlott is valami hasonló, de nem pontosan ugyanez. Minden 
gyártó a maga termékének rendelkezésre állását hirdeti. Eb- 
ben igazán semmi csoda nincs. Csakhogy a saját terméküket 
szeretik , megoldásként" kínálni, mintha az a termék egyedül 
képes lenne a felhasználó problémáját megoldani. A Micro- 
soft is szívesen beszél a Windows szerverek magas rendelke- 
zésre állásáról, ám az már csak kisebb betűkkel olvasható, 
hogy a hardver és egyéb komponensek magas rendelkezésre 
állását feltételezik. Röviden megfogalmazva: bármely gyártó 
bármely termékét is vásároljuk meg, a mi környezetünkben az 
csak egy alrendszer, egy komponens lesz, a hirdetett rendel- 
kezésre állást is így kell tehát kezelni. Érvényes mindez a 
Stratus termékeire is. A felhasználó által tapasztalt stabil szol- 
gáltatásért egyedül mi, üzemeltetők vagyunk felelősek, nem 
pedig a gyártók. 

Még egy apróságot meg kell említeni, — cégektől teljesen elvo- 
natkoztatva. Gyakran előfordul, hogy egy terméket magas ren- 
delkezésre állási mutatóval hirdetnek, csak épp a szolgáltatás- 
kiesésbe nem számítják bele a tervszerű leállásokat. Ha ilyet 
tapasztalunk, az csúnya csúsztatás. Kicsit olyan, mint amikor 
a merevlemez-gyártók kiszámítják termékük kapacitását. Va- 
lahogy a végére mindig egy kicsit kisebb, és még kisebb érté- 
keket kapunk, ha mi formázzuk meg azokat a lemezeket. Hiá- 
ba, -— mindenki felfelé kerekít. 


Harc a hibák ellen 


Műszaki szakembereknek gyakran feláll a szőr a hátán, ha a 
vezetők stratégiáról kezdenek el beszélni, mert az gyakran 
csak üres frázisokat jelent. Mi most a stratégia szót arra hasz- 
náljuk, hogy ,hiba" ellen módszeresen felkészülhessük. Józa- 
nul végiggondolva a következő fázisokat különböztethetjük 
meg: 

1. A hiba még nem létezik. Ezt az időszakot arra lehet fel- 
használni, hogy mind műszaki beruházásokkal, mind 
szervezési lépésekkel felkészüljünk a hiba megelőzésé- 
re, vagyis, hogy ne is következzék be. 

2. A hiba bekövetkezik. Használhatnánk itt a Murphy-féle 
elcsépelt törvényeket, de a fenti okfejtésből világosan 
adódik, hogy a hibák bekövetkezése elkerülhetetlen. A 
hibák egy darabig felderítetlenek. Mi viszont megtehet- 


jük, hogy olyan segédeszközöket működte- 
tünk, amelyekkel a hibák bekövetkezése és 
észlelése közötti idő lerövidíthető. 

3. A hiba észlelése után fel kell állítani a helyes 
diagnózist. Csak miután tudjuk, mi a pontos 
hiba, akkor kezdhetünk hozzá az elhárításhoz szüksé- 
ges teendőkhöz. 

4. A helyes diagnózis megállapítása után két fontos dolog 
következik. Az előre elkészített tervek szerint cseleked- 
ni kell, hogy a szolgáltatást — akár a hiba elhárítása nél- 
kül — helyre lehessen állítani. Itt kapnak fontos szerepet 
a tartalék rendszerek, egy példa ezek közül a fürtszol- 
gáltatás. A másik fontos teendő természetesen a hiba 
kijavításának megkezdése. A javítás alatt előfordul, 
hogy a szolgáltatás nem minden paraméterében felel 
meg a hiba előttinek. A második feladat természetesen 
a hiba tényleges elhárítása. 

5. A hiba kijavítása a megoldással vesz fordulatot, de nem 
ott ér véget. A megoldás után ugyanis még helyre is kell 
állítani a szolgáltatást. 


A főbb fázisokat és egymáshoz való viszonyukat az alábbi áb- 
ra szemlélteti 
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A Helyre- A hibák közötti 
felfedezésig idő Javítási idő állít lá idő idő 
tartó ídi (normál üzemidő) 


A hibák közötti teljes idő 


A hiba 
bekövetkezik 





Észlelés Diagnózis Javítás Megoldás Helyreállítás Új hiba 


E A hibák életciklusa 


A rendszergazdák számára minden olyan eszköz, szoftver, 
technológia, amely a szolgáltatáskiesés idejét, vagyis a hely- 
reállítási időt — felfedezés, reagálás, javítás — csökkenti, hasz- 
nos lehet, mert a teljes rendszer rendelkezésre állását növeli. 
Mielőtt az ftServer-hez és egyéb újításokhoz visszakanyaro- 
dunk, érdemes megvizsgálni, milyen elméleti meggondolások 
segíthetik a rendelkezésre állás növelését. 


Virtualizáció és redundancia 


A rendelkezésre állást sok minden segítheti, akár a lelkiisme- 
retesség is, mégis van két olyan elvi-technológiai megoldás, 
amelyek a leghasznosabbak. Közülük talán a virtualitás a ke- 
vésbé ismertebb. 

A virtualitás mint megoldás abból a meggondolásból szárma- 
zik, hogy a hiba bizonyosan be fog következni, ám jó esé- 
lyünk van rá, hogy ezt a felhasználó elől elfedjük. Tipikus pél- 
da a virtualitásra a RAID tömb. Amikor egy merevlemeztöm- 
böt kialakítunk, a tényleges lemezek fizikai geometriája he- 
lyett logikai (virtuális!) köteteket hozhatunk létre. Elfedjük a 
tényleges valóságot az operációs rendszer elől. Hasonló a 
helyzet a fürtöknél: az ügyfelek nem az egyik, vagy a másik 
node-hoz kapcsolódnak, hanem egy virtuális szerverhez. Szá- 
mukra az a kiszolgáló éppen olyan, mint a többi, s csak a 
rendszergazdák tudják, hogy milyen architektúra dolgozik a 
háttérben. Az ftServerek is erősen építenek a virtualitásra, mint 
elméleti megoldásra. Az operációs rendszer ,nem látja" a 
tényleges valóságot, az igazi hardverelemeket. Sőt, ha bele- 
gondolunk, maga az operációs rendszer is használja ezt a 
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technológiát. Az egyes alkalmazások nem látják, 
hogy a memória, amelyet használnak, fizikailag lé- 
tezik, vagy csak a háttértár egy kijelölt része. A DOS 
alkalmazások szentül meg vannak győződve arról, 
hogy ők az egyedüli futó alkalmazások a rendsze- 
ren, mert a Windows 2000 elrejti a valóságot előlük egy vir- 
tuális gép segítségével. 

A virtualitás azonban igazán a redundanciával együtt szolgál- 
ja hatékonyan a rendelkezésre állást. A RAID5 tömbökben 
mindig legalább eggyel több lemez van, ezzel biztosítva, 
hogy a kontroller a hibákat kijavíthassa és elrejthesse az ope- 
rációs rendszer elől. A virtuális gépeknek szükségük van egy 
másik node-ra, hogy vész esetén újraindulhassanak stb. 

A virtualitásnak és a redundanciának ,két gyermeke" van: a 
hibatűrés és a nagy rendelkezésre állás. A hibatűrés olyan 
technológiai megoldás, amely során a virtualizáció révén a 
meghibásodás magasabb rétegek elől teljes mértékben eltün- 
tethető. A RAID5 és az ftServerek hibatűrő megoldások. A ma- 
gas rendelkezésre állás ezzel szemben nem tünteti el a hibát, 
az láthatóvá válik, ám lecsökkenti a felfedezési és reagálási 
időt. Tipikus példa a fürtszolgáltatás. A virtuális szerverek köl- 
tözése alatt a szolgáltatás nem érhető el, de a kiesés minimá- 
lis az egyetlen szerver esetéhez képest. 

Természetesen a két fogalomnak nem kell feltétlenül együtt 
járnia. A DNS vagy az AD kiszolgálók megkettőzése nem jár 
együtt virtualizációval, mégis növelhető a szolgáltatás bizton- 
sága. 


ftServerek kontra fürtépítés 


A fogalmak megértése után láthatjuk, hogy nincs sok értelme 
összehasonlítani a fürtöket az ftServerekkel. Mert az igaz, 
hogy mindkét technológia a rendelkezésre állást növeli, csak- 
hogy - Héraklész egyik próbájára utalva — a hidra más-más 
fejét vágják le. Az ftServerek hibatűrő technológiájukkal a be- 
következés valószínűségét csökkentik, a fürtök viszont a ma- 
radó kockázat -— tehát a mégiscsak bekövetkezett hiba esetén 
nyújtanak gyors megoldást. Az ftServerek remekül működnek 
mindaddig, amíg van áram, ha azonban egy egész telephely 
marad tápellátás nélkül, akkor egy földrajzilag elosztott fürt 
jelentheti a megoldást. 

Mit jelent mindez számunkra? Több mindent is. Először is 
már tudjuk, hogy a Stratus a saját kiszolgálóinak rendelkezés- 
re állását mutatja a weblapján, nem az ügyfelei teljes rendel- 
kezésre állását. Másrészt a Stratus megoldása nem csodaszer, 
mert csodaszer nincs. Egyetlen eszköz nem elég a százfejű 
szörnyeteg, a szolgáltatáskiesés legyőzésére. Minden techno- 
lógiának megvan a helye a nap alatt. A Stratus ajánlata sem 
csupán egy speciális hardver, hanem — ahogy azt a szeptem- 
beri cikkben olvashattuk — rendszerfelügyelet is. Nem más a 
szándékuk ezzel, mint a hibák korai detektálása, vagyis az 
észlelési- és reakcióidő csökkentése, minimalizálása. 

Ha valaki engem kérdezne, a Stratus megoldást stabil, nem 
változó, nagyon egyszerű (értsd: kevés szolgáltatást nyújtó) 
környezetben használnám. Minimalizálnám a biztonsági koc- 
kázatokat, letiltanám a nem használt szolgáltatásokat, függet- 
leníteném a rendszert a hitelesítési és névfeloldási problé- 


máktól (néha a munkacsoport is elegendő!). Akár egy tűzfal- 
lal is védeném, persze redundáns tűzfallal. A javítócsomago- 
kat különösen megválogatnám, és kizárólag akkor alkalmaz- 
nám őket, ha a konkrét rendszer üzemeltetési tapasztalata 
alapján indokolt. 

A Microsoft cluster megoldása csupán egyike a szoftvercég 
rendelkezésre állást növelő technológiáinak. A felhasználó 
szemszögéből nem jelent hibatűrést, de a szolgáltatás kiesé- 
sét minimalizálja. Nem igényel speciális hardvert, pontosab- 
ban a szükséges alkatrészek nyílt szabványok alapján több 
gyártótól is beszerezhetők. A nem tervezett leállások mellett 
alkalmas a tervezett karbantartás alatt is a szolgáltatás folya- 
matos biztosítására. Tervezése és kialakítása körültekintést 
igényel, alapos kompatibilitási teszteket kell végezni. Az azo- 
nos telephelyű node-ok mellett mód van földrajzilag elosztott 
rendszerek kialakítására is. 


Üzleti megfontolások — végül és elsősorban 


Mielőtt bárki elszalad magas rendelkezést ígérő megoldáso- 
kat vásárolni, ajánlom, hogy végezzen megtérülési számításo- 
kat. Azt kell megbecsülni, vajon a szolgáltatás kiesése kerül 
többe, vagy a technológia, amellyel az üzletmenet folytonos- 
sága biztosítható. Nem mindig és nem mindenhol éri meg 
drága megoldást választani. Lehetséges, hogy üzleti megfon- 
tolások után csupán egy jól megtervezett mentési rendszert, 
esetleg egy katasztrófatervet készítünk, netalán szerződést kö- 
tünk egy vagy több hardverszállítóval, hogy tartalékoljanak 
nekünk alkatrészeket. Miért? Mert ez az olcsóbb. 

Nem született volna meg azonban ez a cikk, meg a korábbiak 
sem, ha a mérleg nyelve nem billenne egyre gyakrabban a 
szolgáltatások kiesését megakadályozó újítások felé. Ebben 
az esetben viszont ajánlom, hogy minden rendszergazda kös- 
se fel a nadrágját, és küzdjön meg derekasan a rendszere Ac- 
hilles-sarkaival és hibáival. Olyan lesz a küzdelem, mint a 
már említett Héraklész próbája a lernai háromfejű hidrával. 
Amikor ugyanis a hidra egyik fejét levágta, másik kettő nőtt a 
helyére, a középső feje pedig halhatatlan volt. A derék Hérak- 
lész rendületlenül vágta a hidra fejeit, ám csak nem bírt vele. 
Végül Lolaosz, az unokaöccse segített neki, együtt győzték le 
a szörnyeteget. 

Ha szeretnénk levonni a tanulságot, annyit mondhatunk, ron- 
da dögökkel egyedül ne kezdjen az ember, még akkor sem, 
ha félisten. A bonyolult rendszerek pedig ronda dögök. 


Lepenye Tamás, MCSE 2000 
lepenyetemal.hu 
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Tanúsítványkijadók 


a Windowsban 


Oualified Subordination 


A Oualified Subordination (kb. ,minősített altanúsítványkiadók") fogalom egy új eszköz- és eljáráscso- 
mag fedőneve a Windows Server 2003 Enterprise Edition nyílt kulcsú szolgáltatásai között. Segítségé- 
vel a tanúsítványkiadók hierarchiájának ágaban szereplő altanúsítványkiadók működését minden ed- 


diginél finomabban testreszabhatjuk. 


A CAPOolicy.inf fájl 


Amikor egy tanúsítványkiadó szolgáltatást telepítünk, a tanú- 
sítványkiadó (CA) nevén, valamint a kulcshossz, kulcstárolási 
mód kiválasztásán kívül túl sok szabadságunk nincs. Az 
altanúsítványkiadók , automatikusan" generálják a tanúsítvá- 
nyuk elkészítéséhez szükséges kérést, majd azt elmentik, vagy 
továbbítják egy elérhető, vállalati tanúsítványkiadó felé. A ta- 
núsítványkérés - és így persze a kérés alapján készített tanú- 
sítvány is — tartalmát és jellemzőit azonban , kívülről", mi is 
befolyásolhatjuk; erre ,való" a CAPolicy.inf fájl. 

Ez a konfigurációs állomány a Windows rendszerkönyvtárá- 
ban (alapértelmezésben C:WWindows) található — vagy ha 
még nincs ott, a CA telepítésekor létrejön. Ha a tanúsítvány- 
kiadó telepítésekor, vagy a saját tanúsítványának megújítása- 
kor ez a fájl létezik, tartalmát a CA feldolgozza, és hozzáiga- 
zítja a készítendő tanúsítványkérést is. A fájl — jó .inf fájlokhoz 
méltóan -— kötelezően mindig az alábbi két sorral kezdődik: 





[Version] — új 
Signaturez"$Windowi 


Ezt követik a különféle beállítások. Ezek közül mutatunk be 
néhányat a következőkben: 


Issuer Statement 


A ,lssuer Statement" jogi szempontból fontos szövegrész, 
amellyel sok tanúsítványban találkozhatunk. Feladata az, 
hogy a szülő CA által kiadott tanúsítványokban felhívja a fi- 
gyelmet a tanúsítványkiadóval kapcsolatos jogi feltételekkel, 
korlátozásokkal kapcsolatban. Az Issuer Statement szöveges 
és/vagy URL formában kerülhet be a tanúsítványokba, ehhez 
a tanúsítványkiadó telepítése (vagy kulcsának megújítása) 
előtt a CAPolicy.inf fájlba fel kell vennünk azt: 








Az OID mező a policy-bejegyzésben kötelező, és az itt látott 
érték természetesen csak példaként szolgál (lásd a cikksorozat 


korábbi részében az OID leírását. 


Az így kért tanúsítvány elkészülte után a jogi szöveg elolvas- 
ható, ha a tanúsítvány tulajdonságlapjának első oldalán az 
,ASssuer Statement" gombra kattintunk: 










§ Refer to the certification authorityis statement for details. 


Issuedto: Falatrax Enterprise Issuer CA I 
Issued by: Falatrax Enterprise Root CA 


valid from 9/8/2003 to 9/8/2005 


Issuer Statement 


3 
(c) Minden jog fenntartva, kivéve ezt-azt 


E Issuer Statement a tanúsítványkiadónk tanúsítványában 





Ugyanitt láthatjuk, hogy a CAPolicy.inf fájlban definiált Issuer 
Statement OID is megjelenik. 

CRL információk, a tanúsítványkiadó tanúsítványa, kulcs- 
hossz, tanúsítvány érvényessége 

A CAPolicy.inf fájlban meghatározhatjuk azt is, hogy a leendő 
tanúsítványban milyen CRL disztribúciós pontok szerepelje- 
nek, valamint azt, hogy hol érhető el a tanúsítványt készítő CA 
saját tanúsítványa (Authority Information Access, AIA mező): 
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Hasonlóképpen, ha a szükség úgy hozná, a [certsrv server] 
szakaszban meghatározhatjuk a leendő tanúsítvány egyéb 
adatait, például: 
JA RenewalkeyLength: megújítás esetén az újonnan gene- 
rált kulcs hossza 
A RenewalvalidityPeriod, RenewalvalidityPerioduUnits: a 
leendő tanúsítvány érvényességi ideje 
FA CRLPeriod, CRLPeriodUnits, CRLDeltaPerion, 


CRLDeltaPeriodUnits: a CRL frissítési időszak meghatá- 
rozása 





Basic Constraints 


A CAPolicy.inf bemutatása után most lapozzunk vissza gon- 
dolatban a tanúsítványok mezőit leíró (néhány hónappal 
ezelőtt megjelent) oldalakra! A mezők között volt egy, a Basic 
Constraints nevű, amely csak a tanúsítványkiadók saját tanú- 
sítványaiban szerepel, ott viszont kötelező jelleggel — tulaj- 
donképpen azt jelzi, hogy az adott tanúsítvány gazdája egy ta- 
núsítványkiadó szervezet. 

A tanúsítványkiadók ismert hierarchiája úgy épül fel, hogy a fa 
alján, a ,sűrűben" működő CA-k tanúsítványait egy másik CA, 
azokét egy újabb, majd a hierarchia mélységétől és bonyolult- 
ságától függően újabb és újabb CA adja ki — egészen addig, 
míg el nem jutunk ahhoz a CA-hoz, akinek saját maga által 
aláírt tanúsítványa van — ő a gyökértanúsítványkiadó (Root 
CA). Mivel elvileg bármelyik tanúsítványkiadó osztogathat ta- 
núsítványt újabb és újabb gyermek CA-knak, előfordulhat, 
hogy a fa kezelhetetlenül bonyolulttá — és nem mellékesen — 
jogi úton zavarossá válik. Ekkor hasznos, ha a tanúsítvány- 
kiadó-tanúsítványt kiadó tanúsítványkiadók ( ;-) ) kezét egy ki- 
csit meg tudjuk kötni, ebben pedig pontosan a Basic 
Constraints segít nekünk. 

A Basic Constraints egyik almezője a Path Length Constraint, 
ami - ha van értéke, és nem , None" — azt határozza meg, 
hogy a kérdéses tanúsítvánnyal rendelkező CA adhat-e ki, és 
ha igen, milyen , mélységig" CA-tanúsítványokat. Ha a CA ta- 
núsítványában a Path Length Constraint értéke 0, az a CA 
gyermek-CA tanúsítványt már nem állíthat ki. Ha mondjuk 2, 
akkor a CA és még az ő gyermeke is adhat ki CA-tanúsítványt 
(mivel a gyermektanúsítványok Path Length Constraint értéke 
mindig eggyel kisebb mint a szülőé), de a 3. generáció CA-i 
már nem. Ha a Path Length Constraint üres (, None"), nincs 
korlátozás. 

Próbaképpen - egyelőre vállalaton belül — hozzunk létre egy 
pici tanúsítványkiadó-fát (egy root és egy kiadó CA-val), ahol 
a gyermek-CA-nak már nem engedjük meg további CA-k ta- 
núsítványainak kiadását. (Vállalaton belül a végtelen és a 0 a 
két ,beállítható" érték, mert azt — látni fogjuk — a tanúsítvány 
Active Directory-beli sablonja definiálja. Vállalatok között a 
Path Length egyéb értékre is beállítható). 

Mivel azonban ez már a Oualified Subordination, egy kis elő- 
készületre is szükség lesz. Mindenekelőtt, szükség lesz egy 
vagy több Windows Server 2003, Enterprise Edition kiszolgá- 
lóra, a Oualified Subordination — a szerkeszthető tanúsítvány- 
sablonok miatt — ugyanis csak ott működik. Ezután, vállalat- 


szerte letiltjuk majd a régi jó, megszokott altanúsítványkiadó- 
tanúsítvány sablont, és egy új, v2.0 tanúsítvány lép majd a he- 
lyébe. Emellett létrehozunk egy új tanúsítványsablont, ame- 
lyet a Oualified Subordination-kérések digitális aláírásához 
használunk — e nélkül az aláírás nélkül az új, jó kis CA- 
tanúsítványunkból senki sem kaphat! 


A meglévő SubCA tanúsítványsablon letiltása 


A Root CA kiszolgálóján nyissuk meg a Certification Authority 
MMC konzolt, majd a tanúsítványkiadó konzolfájában kattint- 
sunk jobb gombbal a Certificate Templates sorra, és válasszuk 
a Manage... parancsot. Erre egy új MMC ablak nyílik meg, 
benne a címtárban található tanúsítványsablonokkal. Kattint- 
sunk a Subordinate Certification Authority sablonra, majd a 
tulajdonságlapjának Security oldalán kattintsuk be az 
Authenticated Users — Enroll jog tiltását (Deny)! Ezzel a , régi" 
sablont kivontuk a forgalomból. 

Oualified Subordination aláíró tanúsítványsablon létrehozása 
Hozzuk most létre a kérés aláírásához szükséges tanúsítvány 
sablonját! Az Administrator sablonon jobb gombbal kattintva 
válasszuk a Duplicate Template parancsot, a létrejövő új tanú- 
sítványsablonnak pedig adjuk a hangzatos ,Oualified 
Subordination Reguest Signing" nevet. 
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To modiíy an extension, select it, and then click Edit. 


Extensions included in this template: 
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A Oualified Subordination Reguest Signing sablonban 
egyetlen Application Policy szerepel: a Oualified 
Subordination 


Miután létrehoztuk és elneveztük az új tanúsítványsablont, 
lépjünk az Extensions oldalra, ott pedig az Application 
Policies tartalmából töröljünk mindent, és vegyük fel a 
Oualified Subordination policy-t. Ezután a Security oldalon 
ellenőrizzük, hogy csak megfelelő felhasználók (mondjuk az 
Administrators csoport) rendelkezzen a sablonra Enroll joggal. 


Új gyermektanúsítványkiadó tanúsítványsablon létrehozása 


A következő lépés a letiltott SubCA sablon utódjának elkészí- 
tése. Ehhez a fentihez hasonló módon duplikáljuk a régi 
SubCA sablont, az újszülöttet pedig nevezzük el Subordinate 


tech.net 


Certification Authority v2.0-nak. Ezután itt két dolgot kell mó- 
dosítanunk: 
A A Basic Constraints bővítményben a Path Length 
Constraint értékét 0-ra állítani 
TA A tanúsítvány kéréséhez előírni a digitális aláírás szük- 
ségességét 


A Basic Constraints beállításait a tanúsítványsablon tulajdon- 
ságlapjának Extensions oldalán találjuk: 





Subordinate Certification Authority v2.0 P 21x 
General Issuance Reguirements l 
Superseded Templates Extensions Security l 


To modify an extension, select it, and then click Edit. 


Extensions included in this template: 





(—] Application Policies 

[79 Basic Constraints 

Ell Edit Basic Constraints Extension "8 
Issuar 


[E]KeyU The subjectis a certification authority (CAJ. 





21xI 





[7 Make this extension critical 
E A Path Length Constraints 0-ra állítása 


A Do not allow subject to issue certificates to other CAs pipa 
elhelyezése a háttérben 0-ra állítja a sablon alapján kiadott ta- 
núsítványok Path Length Constraints értékét. 

Az aláírásigényt pedig — már ismert módon — az Issuance 
Reguirements oldalon nyújthatjuk be: 





ET a e en aa sa 1 21xi 
Superseded Templates ] Extensions ] Security 1 
General Issuance Reguirements 


Reguire the following for enrollment: 

IT CA certificate manager approval 

(7 This number of authorized signatures: ír 

If you reguire more than one signature, autoenrollment is not allowed. 
Policy type reguired in signature: 

Application policy hu 


Applicati Mic: 
Oualified Subordination E 








Reguire the following for reenrollment: 
(Same criteria as for enrollment 
C Valid existing certificate 





aa 


A tanúsítvány kéréséhez Oualified Subordination 
Application Policy-t tartalmazó tanúsítvánnyal történő 
digitális aláírás szükséges 


Egy nagyon fontos momentumról ne feledkezzünk meg: ez a 
tanúsítványsablon a letiltott SubCA sablonból készült, ezért 
,örökölte" annak biztonsági beállításait is! Úgyhogy mielőtt 
továbblépnénk, a mellékhatások elkerülése érdekében töröl- 


achnet tf táj wit 


jük az új tanúsítványunk Security oldalán az Enroll 
tiltó jogát! 


Ezzel a gyökértanúsítványkiadót előkészítettük. 9 
Most , üljünk át" gondolatban a gyermek CA-hoz, és 
kezdjünk munkához! 


Gyermek-CA tanúsítványának telepítése / frissítése 


Most két lehetőségünk van: vagy még a CA telepítése előtt lét- 
rehozzuk a CAPolicy.inf fájlt, vagy pedig a CA-t telepítjük (ta- 
núsítványt a gyökér-CA-tól úgysem kaphat, hiszen a SuDCA 
sablon le van tiltva, az új sablonról pedig egyelőre rajtunk kí- 
vül senki sem tud), és a CA tanúsítványának , megújítását" vá- 
lasztjuk. Mindegy, hogy melyiket választjuk, először is a CA- 
val közölnünk kell, hogy nem a SubCA-ból, hanem egy attól 
különböző tanúsítványsablonból kell tanúsítványt kérnie. Eh- 
hez (és ebben az esetben csak ehhez) a CAPolicy.inf fájlt kell 
szerkesztenünk: 


Ele Edit Format Yew Help 
Version] 
Signaturez"$windows NT$" 








[Reguestattributres] 
ertifi cateremplatessubordínatecertificationauthorityv2.0 
2 A sablon nevét a CAPolicy.inf fájl [ReguestAttributes] 
szakaszában állíthatjuk be 


Ha most megpróbálnánk megújítani a tanúsítványkiadónk ta- 
núsítványát, az a sablont már megtalálná, ennek egyik bizo- 
nyítéka az is, hogy a kérés befejeztével csúnya hibaüzenet 
várna: 





Sibordnatecertfk catlonauthortyvi 0 Certíicate Temolate spedhes, because the 
template validity period is longer than the maximum certificate validity period allowed by. 
the the CA certificate, reducing the template validity pertod, or 
increasing the registry validity period. 


Parent CA — server2003.falatrax2003.hulFalatrax Enterprise Root CA, Reguest ID — 
GTANOSÉN TTI FEK MTNKER KÉK HEGYÉN 0x80094809 
2146875383) 





Do] 





E A kérés digitális aláírása nélkül márpedig tanúsítvány 
nem jár! — üzeni a Root CA 


Úgyhogy nem tehetünk mást, mint a tanúsítvány-megújító fo- 
lyamat vége előtt egy pillanattal (a tanúsítványkiadó kiválasz- 
tásának ablakában) megállunk, a kérést fájlba mentjük, és át- 
vesszük a parancsnokságot. 


(ENSZ Es XI 





Select an online CA to send the reguest 


Computer Name:  [server2003.falatrax2003.hu Browse... 
Farent CA: Falatrax Enterprise Root CA r] 





B A cKkérés mentéséhez kattintsunk a Cancel gombra. 
A kérés fájlnevét az ablak közepén megtaláljuk 
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- gnalitied Subordination [dd 0 1 5 


Tanúsítványkiadók a Windowsban 


2b 


Jegyezzük meg ezt a fájlnevet, mert a továbbiakban 
ezzel fogunk dolgozni. 

A tanúsítványkérés digitális aláírása 

A digitális aláíráshoz mindenekelőtt szükség lesz 
egy aláíró tanúsítványra. Ez a tanúsítvány — és a vele készült 
aláírás — bizonyítja majd, hogy a gyermek CA tulajdonosa jo- 
gosult a tanúsítványláncba léptetni kiszolgálóját. Valós eset- 
ben az aláíró tanúsítvány valószínűleg valakinek a személyes 
kulcstároló eszközén, smart cardján foglal helyet, a példa ked- 
véért most kérjünk egyet a gyermek CA Administrator felhasz- 
nálójának (jelentkezzünk be a Root CA webes felületére, és 
válasszuk ki a Oualified Subordination Reguest Signing tanú- 
sítványsablont). 





[ZETT ETETETT ET zDl2d 


igyögertreg -policy "örwu2könenber. falatrax2003.hu Palatrax Enterprise Issuer CA 
-reg" 


(EZTTZTETET NENT 21 


Ut Enrölment Regjstratjon Agent certficates 


LL 











E A kérés aláírásához ki kell választanunk az aláíró-tanú- 
sítványt 


A fájlba mentett kérést a 





paranccsal írhatjuk alá digitálisan. A parancs kérni fog egy .inf 
fájl nevet, itt adjuk meg a CAPolicy.inf-et, azután a megjelenő 
ablakban válasszuk ki az aláíró tanúsítványt. Az aláírt kérést 
mentsük ismét fájlba — e fájl tartalmát kell majd a gyökér CA 


webes felületén elküldenünk. 





Zlmkrosoft Certificate Services - Microsoft Internet Esplorer 
le Edt em  Füvortes Too tieb 
GBark e I (d id) A] 2 Szardh 7 Favortos td Mode € ea 








eéress [E hp tfserverző0sízensreeervest 380 zi 








Semíces -. Falatrax Enterprise Root CA 


Subrmit a Certificate Reguest or Renewal Reguest 





To submit a saved reguest to the CA, paste a base-64-encoded CMC or PKCS 410 certificate reg 
PKCS 7 renewal reguest generated by an external source (such as a Web server) in the Saved Rt 


Saved Reguest: 





jang 1eTANBgkahkiGSVOBAOEFAASBGFEKZ 1/ 6tTIV.2] 
Base.64-encoded [Lb1S/OORJ1T1824UISKOSFO£IR10043t Z6HDSSJV 
Certificate regyeet s 102VAZSSI SDKBEAKJ VAHZCSOHAKAGYNTUT AOL IT 





(CMC or EGYV.KBZ 
PKCS AID or [——--i END NEW CERTIFICATE REGUEST----- 
PKCS 47) 
4 . 
Biowze for a Ő 





Certificate Template: 


Subordinate Certiicaton Authorty 20. 5] 








E A webes kérésbe másoljuk be az elmentett, aláírt 
kérésfájl tartalmát és ne felejtsük el kiválasztani a meg- 
felelő tanúsítványsablont! 


A gyökér CA ezt a kérést már szívesen kiszolgálja, az ered- 
ménykérnt keletkező .cer fájlt mentsük el, majd a gyermek-ta- 
núsítványkiadó MMC konzoljában válasszuk az Install CA 
certificate... parancsot. Itt adjuk meg az újonnan készült .cer 
fájl nevét és készen is vagyunk. 


Falatrax Enterprise Issuer CA Propé 


Certificate Managers Restrictions ] Auditing ] Recovery Agents ] Security ] 
General] PolieyModule ] ExítModule ]  Estensions ] Storage ], 


General  Detais ] certification Path 














Show: [Als ha 
Field Value ja 
certificate Template Inform... . Templatezsubordinate Certific. , . 
E authority Key Identifier KeyID-14 30 cc d2 46 c9f2 5... 
FH cRL Distribution Points ([1]CRL Oistribution Point: Distr. . . 


Fáauthority Information Access — [1]Jáuthority Info Access; Ar 







FEJ Thumbprint algorithm shal 


sg Thumbprint 
ssjextended Error Information 


Subject TypezCA 
Path Length Constraint-0 


id7bá4469edfcb3ccd9el ,.. 
Revocation Status : OK, Effec,,, 





S A gyermek-tanúsítványkiadó tanúsítványa: látható 
a Path Length Constraint 0 értéke 


A tanúsítványkiadónk ezennel elkezdheti a munkát, belépett a 
tanúsítványkiadók hierarchiájába, de a tanúsítványában sze- 
replő korlátozásoknak ,köszönhetően" csak felhasználói ta- 
núsítványokat adhat ki. 


A következő részben folytatjuk a Oualified Subordination be- 
mutatását, a , maradék" három korlátozó policy-vel. Most jön 


még csak a java! 


Folytatjuk... 


Fülöp Miklós 
mick€inetcom.hu 
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Igényfelmérés, követelményanalízis 


Hiába vagyunk a piac legnagyszerűbb fejlesztői, hiába találjuk ki a leghatékonyabb algoritmusokat, 
hiába dolgozunk a legmodernebb technológiákkal, ha egy dolgot nem tartunk szem előtt: a fő cél az 


ügyfelek elégedettsége. 


Bizonyára mindenki ismeri azt a szituációt, amikor sok-sok át- 
virrasztott éjszaka, a gép mellett töltött hétvégék után büszkén 
rohanunk ügyfelünkhöz, hogy időben odaérjünk a 10 perce 
még warningokkal teli, de az utolsó pillanatban valami csoda 
folytán mégis forduló és futó, kész alkalmazással. Büszkén lé- 
pünk be az ajtón, beesett szemünk álmosan pislog, de csillog 
a lelkesedéstől, hogy kijelenthetjük: készen vagyunk! 

Az ügyfél visszafogottan örül. Elővesszük táskánkból a 
notebook-ot, hogy megmutathassuk, milyen is lett a legújabb 
szülemény. Ám ahogy a program elindul, az ügyfél egyre sá- 
pad, majd hirtelen vörösbe csap át arcszíne, és bármilyen lel- 
kesen mutogatjuk is a funkciókat, egyszer kitör belőle: , De hi- 
szen ez így nem jó, mi nem ezt kértük!" 


Ki a , hibás"? 


Ilyenkor persze elkezdődnek a csatározások, mindenki a saját 
álláspontját védi: a megrendelő váltig állítja, hogy ő elmond- 
ta, mit szeretne, és nem érti, hogyhogy nem voltunk képesek 
megérteni?! Mi viszont abban vagyunk egészen biztosak, 
hogy egészen pontosan azt valósítottuk meg, amit kértek tő- 
lünk, és nem értjük, miért változik folyamatosan a vevő igé- 
nye az időjárásnak és a csillagok állásának megfelelően. 

Ha ilyenkor külső szemlélőként tudnánk vizsgálni a dolgokat, 
érdekes tanulságokat szűrhetnénk le (azon kívül persze, hogy 
pszichológiai szempontból magunkat is jó lenne időnként kí- 
vülállóként látni). Az esetek többségében azt tapasztalnánk 
ugyanis, hogy tulajdonképpen mindenkinek igaza van... 


Kommunikációs hiányosságok 

A probléma gyökere tulajdonképpen abból ered, hogy nem 
vagyunk egyformák. A megrendelő többnyire nem informati- 
kus szakember, mi pedig nem értünk az ő szakmájához. Így 
aztán nem is csoda, ha az egyeztetések során elbeszélünk 
egymás mellett, és nem értjük, ami a másik számára triviális. 
Úgy tűnhet tehát, hogy egy tolmácsra lenne szükségünk, aki 
ért ,informatikusul" is, és az adott megrendelő szaknyelvén is: 
gyógyszerészül, közgazdászul, politikusul, távközlésül stb. 
Ilyen emberek azonban vagy nem léteznek, vagy számunkra 
elérhetetlenek, így csak magunkra hivatkozhatunk. A megren- 
delő általában nem ismeri fel a közös nyelv megtalálásának 
szükségét, mert úgy érzi, teljesen triviális, amit mond, és nem 
is érti, hogy lehet nem érteni őt. Néha megpróbál ugyan infor- 
matikus kifejezéseket használni, de sok esetben ebből is csak 
félreértések vagy mosolyogtató élmények születnek (pl.: ,a 
rendszer lefagyás-szerű dolgot szimulál..." 0). Ezért nekünk 
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kell felkészülni az ilyen típusú problémák kezelésére még ak- 
kor is, ha ez nem egészen mérnöki típusú feladat. 

Így a felhasználói igények felmérésénél nagyon oda kell fi- 
gyelnünk, mit és hogyan rögzítünk. Ez azonban még mindig 
nem elég: a fejlesztés során folyamatosan egyeztetni kell a fel- 
használóval, hogy az adott modult, funkciót valóban így kép- 
zelte-e el, hiszen menet közben sokkal egyszerűbb (és ol- 
csóbb) módosítani a rendszert, mint az átadás után — vagy he- 
lyett. 

Többször tanúja voltam már annak, hogy a követelmények 
nem megfelelő rögzítése esetén maradtak , !yukak", amelyeket 
a projekt végén a felhasználó természetesen megpróbált ki- 
használni (nem feltétlenül rosszindulatból, csupán saját akara- 
ta érvényesítése céljából). Ilyenkor szokott az történni, hogy a 
zárás előtt feláll a vevő, és közli, hogy ő tulajdonképpen még 
ezt és ezt a dolgot beleértette a specifikációba, amelyben ez 
nem szerepel ugyan, de ki sem zárja azt. És jönnek az éjsza- 
kába nyúló alkudozások: hatásköre-e még ennek a projektnek 
(és a hozzá tartozó költségvetésnek) ez a módosítás/kiegészí- 
tés (a megrendelő szerint: hibajavítás), vagy már csak egy kö- 
vetkező fázisba fér bele? 


Nehéz megfogalmazni, hogy mi is kell ahhoz, hogy megértsük 
az ügyfelet, és megértessük magunkat vele. Egyrészt kell egyé- 
ni adottságok egész sora, amelyek fejleszthetők ugyan, de a 
szó hagyományos értelmében nem tanulhatók; másrészt elsa- 
játítható ismeretek, tapasztalatok is szükségesek. 
Természetesen ezen ismeretek megszerzéséhez idő kell. Egy- 
részt áldozni kell az elméleti tudás megszerzésére, másrészt a 
gyakorlatban is el kell sajátítani, ami elméletileg már a fejünk- 
ben van, hiszen az kb. annyit ér gyakorlati tapasztalat nélkül, 
mint ha valaki oda-vissza bemagol egy szakácskönyvet, amely 
alapján még soha nem főzött — így azt sem tudja, melyik re- 
cept rejteget finom süteményeket, és melyiket kell módosítani 
valamelyest — esetleg melyik az, amelyik teljesen használha- 
tatlan. 


Az ügyfél-kommunikáció 

Az ügyféllel folytatott kommunikáció egyik alapfeltétele, hogy 
valamelyest értsünk a szakterülethez, amelyet ő képvisel. Ter- 
mészetesen nem kell profinak, szakértőnek lennünk, hiszen 
akkor mi ülnénk az ő pozíciójában, viszont elengedhetetlen, 
hogy a projekt során egy nyelvet beszéljünk. Ebben elsősor- 
ban maga a megrendelő nyújthat nagy segítséget számunkra, 
viszont az együttműködéshez a mi kezdeményezésünkre van 
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szükség. A projekt előkészítése során kérdezzünk rá 
minden kifejezésre, amit használ, esetleg kérjük 
meg, állítson össze egy szótárat számunkra. Egy má- 
sik lehetőség, hogy amennyiben írásos anyag áll ren- 
delkezésünkre a témában, annak elolvasása során 
mi magunk jegyzeteljük ki a kérdéses szavakat, kifejezéseket. 
Ez a szótár természetesen folyamatosan bővül az idő múlásá- 
val. Egyetlen dolgot tartsunk szem előtt: kérdezni nem szé- 
gyen, sőt! Egykori filozófiatanárom szerint aki nem tud kér- 
dezni, az nem is érti, miről van szó. Mennyire igaza volt! 
Persze nem elég a megrendelő szavainak megértése, azzal is 
tisztában kell lenni, egy-egy mondatot hogyan ért, mit gondol. 
Ehhez fontos igazán a kérdezés! Mindig tartsuk szem előtt, 
hogy a felhasználó csak körvonalakban tudja, mit szeretne, és 
még azt is csak korlátozott módon tudja megfogalmazni! 
Tegyük fel például, hogy a megrendelő egy olyan robotot sze- 
retne felprogramoztatni velünk, amely sütemények elkészíté- 
sére képes. Hogy egyszerűbb legyen a dolog, a robot ,gyer- 
mekkorában" még csupán piskótatésztát képes sütni, tudását 
egy későbbi fázisban szándékozunk továbbfejleszteni. Lássuk 
először azt a megoldást, amikor nem kommunikálunk eleget 
az ügyféllel. 


Két mondatban elmeséli, hogy ilyen robotot szeretne, és a fan- 
táziánk azonnal beindul: van némi fogalmunk arról, hogyan 
készül a piskótatészta, ezért nem is firtatjuk tovább, azonnal 
nekiállunk fejleszteni a rendszert. A robot egyre ügyesebb, 
csodálatos tésztát kever, szép sárgára kisüti — mehetünk a 
megrendelőhöz, készen vagyunk. 


Pig 
recept 





B A Fpiskótakészítés folyamata 


Most jön az, amit nem várunk: a cukrász ügyfél halálsápad- 
tan közli, hogy a piskótatészta nem így készül, mert ő még cit- 
rom héját is szokott reszelni bele, és különben is, ezen a hő- 
fokon nem jó sütni, hiszen ha 5 fokkal melegebb a sütő, sok- 
kal szebben feljön a tészta, és a színe is szebb lesz. 
Rendben, hazamegyünk, leprogramozzuk az újabb igénye- 
ket. Működik, mehetünk a megrendelőhöz, készen vagyunk... 
Ezt a lépést háromszor-négyszer megismételve eljutunk 
odáig, hogy a vevő hajlandó lesz átvenni a robotprogramot. 
Elégedetten dőlünk hátra, elkezdjük tervezgetni, mit is kez- 
dünk azokkal a milliókkal, ami most a számlánkra érkezik 
majd. Már-már elnyom bennünket az álom, azonban ekkor 
megszólal a telefon. Cukrász barátunk sikítva közli, hogy a 
robot elejtett egy tojást, és ettől teljesen összezavarodott, 
most éppen a fokhagymasót önti kilószámra a tésztába. 

Ja tényleg, a hibakezelés valamiért kimaradt, hiszen olyan tri- 
viális egy piskótatésztát megsütni, eszünkbe sem jutott... Újra 
nekiállunk hát programozni, és próbáljuk összeszedni, mi- 
lyen hibákat követhet el a robot, illetve milyen külső ténye- 
zők befolyásolhatják a piskóta sikeres elkészülését (például 


ha egy tojás már záp, nem túl szerencsés beleütni a tésztába). 
Mindezek az újabb és újabb iterációk sokkal több időt, ener- 
giát vesznek igénybe, mintha már a kezdetektől figyelembe 
vettük volna ezeket a tényezőket. Ezt valahogy érezzük, 
viszont azt nem tudjuk megmondani, mi az, amit másképp 
kellett volna csinálnunk, hiszen az ügyfél tehet mindenről, 
ő az, aki nem mondott el mindent részletesen. Honnan kelle- 
ne ilyen pontosan tudnunk egy piskótasütés minden csínját- 
bínját...? 

Leülünk tehát gondolkodni, hogy lehet az, hogy mindig van 
valami félreértés a megrendelő és közöttünk, nem volt még 
egyetlen olyan projektünk sem, ahol ne történt volna hasonló 
eset... Kétségbeesésünkben rábukkanunk a [tervbaki] URL-en 
található képsorozatra, és hangos üdvrivalgásban törünk ki, 
látva, hogy ez nem csupán számunkra okoz problémát... 


A megoldás 


A megoldást az jelentheti, ha a megrendelő igényeit pontosan 
rögzítjük, mégpedig úgy, hogy kellően formális legyen ahhoz, 
hogy később ez alapján meg tudjuk tervezni a rendszert, vi- 
szont a megrendelő számára is érthető, hétköznapi nyelven 
legyen megfogalmazva. 

Mindezen feltételeknek tesznek eleget a Use Case-ek, (ma- 
gyarra ferdítve: használati esetek), melyek célja a funkcionális 
követelmények. szisztematikus leírása. Hogyan is néz ki 
mindez? 

A megrendelő igényeinek felmérése közben nem elég, ha ő 
megmondja nekünk, milyen folyamatot kell megvalósítanunk, 
azt is tisztázni kell, hogy milyen lépésekből áll ez a folyamat. 
Felépítünk tehát egy forgatókönyvet, amely a folyamat sikeres 
lefutásának lépéseit tartalmazza. A fenti példánál maradva, a 
sikeres piskótasütés lépései az alábbiak lesznek (cukrász bará- 
tunkkal történt egyeztetésünk után): 


1. Hozzávalókat összekészít. 





2. Tepsit kivajaz, sütőt begyújt. 

3. 12 tojást felüt, sárgáját és fehérjét szétválaszt. 

4. Asárgájába belekever 12 evőkanál cukrot, majd habos- 
ra ver. 

5. A fehérjébe tesz 1 csipet sót és kevéske porcukrot, majd 

habosra ver. 

A habos fehérjét óvatosan a sárgájába kever. 

Hozzákever lassan, egyenletesen 12 evőkanál lisztet. 

A tepsibe önt, a tepsit a sütőbe tolja. 

Aranysárgára süt. 
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Ezeket a lépéseket kell tehát megvalósítania a rendszernek, ez 
az a forgatókönyv, amelynek minden lépése sikeres, így ter- 
mészetesen a végső kimenetel is. Ezt szemlélteti az alábbi áb- 
ra, amelyet a későbbiekben tovább építgetünk (a számok a 
fenti, sorszámozott lépéseket jelölik): 








E A sikeres lefutás menete 


A sikeres lefutást tehát a megrendelővel karöltve leírtuk, így 
ezt már tudjuk, hogyan kell megvalósítani. Ekkor viszont egé- 
szen biztosan előjönnek azok a lehetőségek, amikor egy-egy 
lépés sikertelen ugyan, valamilyen hiba lép fel, de ez a prob- 
léma még orvosolható, így végül a folyamat egészét tekintve 
sikeres lefutást kapunk. 
Ilyen eset lehet például, ha a robot elejt egy tojást, amely 
összetörik, de megoldást jelenthet egy újabb tojás elővétele. 
Ezeket a lépésenkénti aleseteket úgy jelöljük, hogy az eredeti 
lépés sorszáma mögé elkezdjük felsorakoztatni az ABC betűit. 
Például: 
3. 12 tojást felüt, sárgáját és fehérjét szétválaszt. 
3a. Tojás eltörik, újat vesz elő. 
3b. Tojás megromlott, újat vesz elő. 


7. Hozzákever lassan, egyenletesen 12 evőkanál lisztet. 
7a. Liszt kiborul, új csomagot vesz elő. 


Ennek megfelelően a fenti ábra kiegészíthető a hibás eseteket 
lekezelő, úgynevezett kiegészítő forgatókönyvekkel: 





E A rpiskótasütés folyamata a kiegészítő forgató- 
könyvekkel 





pls 
tecn.net WűárEdttű Witt Hl 


Jól látható, hogy az első oszlop továbbra is a főfor- 
gatókönyvet tartalmazza, míg a többi a tojástörést il- 
letve lisztkiömlést, a legutolsó forgatókönyv szerint 
dolgozó robotot pedig valószínűleg rövid idő alatt 
leselejtezi a tulajdonosa, hiszen minden lehetséges 
hibát elkövet. 


A fenti Use Case-ek tehát a sikeres lefutású forgatókönyveket 
írják le, lépésről lépésre, pontosan definiálva minden egyes 
műveletet. S mindezt úgy, hogy a cukrász megrendelő is 
könnyedén megértse. Természetesen ezek a Use Case-ek foly- 
tonos egyeztetések során jönnek létre, az ügyféllel közösen 
alakítjuk ki őket. Annak köszönhetően, hogy lépésről lépésre 
mindent végiggondolunk, benne is tisztázódik, hogy pontosan 
mit és hogyan szeretne, a ködös elképzelésekből kirajzolódik 
a majdani rendszer váza. 

(Egy ismerősöm szerint olyan ez, mint egy ember csontváza. 
Ha viszont már az elején rosszul rögzítjük a követelményeket, 
soha nem lesz a vázból énekes halott...) 


A valóságban azonban nemcsak sikeres lefutás létezik, hanem 
esetenként meghiúsul az egész műveletsor. Ezt is tudni kell 
modellezni. 

Természetesen a Use Case-ek erre is használhatók. A sikeres 
lefutáshoz hasonlóan leírhatjuk azokat az aleseteket is, ami- 
kor egy-egy lépés meghiúsulása a teljes folyamat meghiúsulá- 
sához vezet. 


Lássunk erre is néhány példát: 


1. Hozzávalókat összekészít. 
1x. Nincs meg minden 2 Meghiúsulás. 


3. 12 tojást felüt, sárgáját és fehérjét szétválaszt. 
3x. Tojás eltörik, nincs otthon több 3 Meghiúsulás, 
3y. Tojás megromlott, nincs otthon több 3 Meghiúsu- 
lás. 


7. Hozzákever lassan, egyenletesen 12 evőkanál lisztet. 
7x. Liszt kiborul, nincs otthon több 3 Meghiúsulás. 


9. Aranysárgára süt. 
9x. Piskóta megég 3 Meghiúsul. 


Napestig sorolhatnánk a hibalehetőségeket, amelyek meghiú- 
sítják a folyamatot. Ezek mélysége természetesen a felhaszná- 
ló igényeitől függ elsősorban, azonban azt mindenképp figye- 
lembe kell venni a fejlesztés során, hogy a konkrét hibák leke- 
zelésén túl az előre nem látott eshetőségekre is fel kell készí- 
teni a rendszert. Például ha csak a fenti hibaeseteket vesszük 
figyelembe, a robot akkor se omoljon össze, ha esetleg a 8. lé- 
pésben kiborítja a tepsi egész tartalmát. 


Ennek megfelelően az eddig építgetett ábránk végleges, a hi- 
balehetőségeket is tartalmazó formája: 
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" Igényfelmérés, 


Találd el a felhasználók igényeit!. 
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Meghiúsulás 


B A piskótasütés lehetséges forgatókönyvei 


Sikeres lefutás 


Ha Lagzi Lajcsi tudta volna, hogy közismert nótájában a Use 
Case-ek rejtelmeibe vezet be bennünket!... 9 (Megkérdeztem 
a szerzőt, mégis mire gondol: , Van nekem egy csíkos ga- 
tyám...", lásd a fenti ábrát. — a szerk.) 


További lépések 

A Use Case-ek segítségével leírhatjuk tehát, hogy mit szeret- 
ne a megrendelő, de természetesen ez nem elég ahhoz, hogy 
az elképzelésből működő rendszer legyen. A formailag ugyan 
kötött, de köznyelven megfogalmazott Use Case-ek kiindulá- 
si pontot adnak a további tervezéshez. 

Igen ám, merül fel ilyenkor a jogos kérdés, de hogyan men- 
jünk tovább, mi legyen a következő lépés, ha már tudjuk, mit 
kell megvalósítanunk? Honnan fogjuk tudni, hogyan valósít- 
suk azt meg? 

A rendszer megtervezéséhez először is nagyfokú rálátásra van 
szükségünk: ha már ismerjük az ügyfél igényeit, el kell tud- 
nunk dönteni, melyik technológia a legalkalmasabb annak 
megvalósítására. Természetesen ennek eldöntéséhez nem 
csupán szakmai szempontok figyelembevételére van szükség, 
hanem egyéb dolgokat is mérlegelni kell. 

Először is a vevő anyagi és egyéb erőforrásaira kell tekintettel 
lennünk: ha nem engedheti meg magának, hogy milliós nagy- 
ságrendben ruházzon be szerverekre, szoftverekre és egyéb 
komponensekre, valószínűleg nem célszerű ebbe az irányba 
indulni. Figyelembe kell venni, milyen hardverek és szoftve- 
rek állnak rendelkezésére: ha a vállalati struktúra alapvetően 
Windows szerverekre és kliensgépekre épít, nem célszerű 
Linuxos rendszer kifejlesztésén gondolkozni, legalábbis erő- 
sen mérlegelni kell, és erős érveket kell felsorakoztatni ahhoz, 
hogy mégis így döntsünk. 

Tekintettel kell lennünk a rendelkezésre álló időre is: munkám 
során többször találkoztam már azzal a hozzáállással, hogy 
nem a feladathoz kellett igazítani a határidőt, hanem a határ- 
időhöz a feladatot. Ez persze nem egészséges megoldás, de a 
gyakorlatban mégis létezik: a megrendelő azt tudja, hogy pél- 
dául 6 hónapon belül szeretne egy ilyen meg ilyen rendszert. 
A pontos funkciók még nem tisztázódtak benne, de abban 
egészen biztos, hogy 6 hónap múlva már használni szeretné. 
Ilyenkor jön az a fajta egyeztetés, amikor a követelmények 
rögzítése, a Use Case-ek felállítása közben már arra is figyel- 
nünk kell, hogy vajon beleférünk-e a megadott időkorlátba. 
Lássunk egy példát: A felhasználó egy piskótasütő robotot 
szeretne. A megbeszélések során felmerül, hogy jó lenne, ha 
nemcsak ki tudná sütni a piskótát, hanem különféle krémeket 


is keverne rá. Ez azonban újabb problémákat vet fel: egyrészt 
újabb funkciókat jelent, másrészt újabb erőforrásokat is, hi- 
szen pl. tej nem kell a tésztához, de a krémhez egészen biz- 
tosan. Ha azt látjuk, hogy ennek megvalósítása legalább 3 hó- 
napot venne igénybe, és ezzel már 8 hónapra nőne a szüksé- 
ges idő, akkor nyilván nem szabad vállalni ennek a funkció- 
nak a megvalósítását. (Vagy későbbi fázisra halasztani.) 
Néhány szó az időről 
Az idő mindig kritikus kérdés, ennek megfelelően nagyon kö- 
rültekintően kell bánnunk vele. Ahhoz, hogy a teljes folyamat 
időigényét becsülni tudjuk, először is részfolyamatokra kell 
bontanunk azt. Egy szoftverprojekt alapvetően négy fázisra 
bontható: 

A Előkészítés 

AA Tervezés 

HA Megvalósítás (fejlesztés, tesztelés) 

HA Lezárás (átadás, működtetés) 


Az előkészítés során a legintenzívebb a kommunikáció a 
megrendelővel, hiszen ekkor rögzítjük a követelményeket, 
megszületik a funkcionális specifikáció. A tervezés már első- 
sorban mérnöki, informatikusi feladat, a megrendelővel la- 
zábbá válik a kapcsolat, ritkulnak a találkozások. Nagyon 
fontos azonban, hogy a kapcsolatot lehetőség szerint folya- 
matosan tartani kell, hiszen a vevő akkor tud konstruktívan 
részt venni a folyamatban, akkor tud segíteni, ha engedjük 
neki. A megvalósítás során ,kódoljuk" le a megtervezett funk- 
ciókat, ez az a fázis, ahol a klasszikus értelemben fejlesztünk. 
Az utolsó szakaszban történik a rendszer átadása, 
beüzelemése, a felhasználók betanítása, stb. 

Jól látható módon ezzel a felbontással máris elindultunk a 
részfolyamatra bontás útján. Az egyes fázisokat tovább már 
csak a szakértők bevonásával oszthatjuk, és a szükséges idő 
megbecsüléséhez is fontos az ő bevonásuk. 

A folyamatokat eleminek tekinthető teendőkre bontjuk tehát, 
majd ezekhez a teendőkhöz időtartamokat rendelünk. Ha fel- 
tételezzük, hogy ezek a teendők nem párhuzamosíthatók, a 
teljes időigény természetesen ezek összege. A valóság azon- 
ban általában az, hogy bizonyos teendők párhuzamosíthatók, 
míg mások egymásra épülnek. Ezeket az összefüggéseket egy 
gráfon ábrázolhatjuk. Egy példát mutat az alábbi ábra: ki 
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E Tevékenységek grafikus ábrázolása 


A fenti ábrán a nagybetűvel jelölt körök egy-egy mérföldkövet 
jelentenek, vagyis elérendő állapotot, megvalósítandó célt, a 
közöttük futó irányított nyilak pedig a tevékenységeket, rajtuk 
az elvégzésükhöz szükséges időtartam, például hetekben ki- 
fejezve (a mértékegység tetszőleges, azonban használatának 





következetesnek kell lennie). A folyamat tehát az A állapotban 
kezdődik. Ahhoz, hogy innen eljussunk a B-be, 3, a C-be 2 
hétre van szükség. A nyilak párhuzamossága a tevékenységek 
párhuzamosítására utal, ez a két teendő tehát végezhető egy 
időben. A B állapot elérése előfeltétele annak, hogy tovább- 
lépjünk D-be, a C pedig mind a D-nek, mind az E-nek. A be- 
fejező E állapotnak azonban a D is feltétele. 

Lássuk, mennyi idő szükséges a folyamat teljes befejezésé- 
hez: B-be 3 hét, C-be 2 hét alatt jutunk el. D-hez egyrészt be 
kell fejezni a B-t követő 4 hetes munkát, másrészt a C-t köve- 
tő 6 hetest, így a két kritérium: a B-n áthaladó 3--4-7 hetes, a 
C-n áthaladó 2--6-8 hetes feladatsor befejezése. Mivel ez a 
két feltétel ÉS kapcsolatban áll egymással, a D állapot legha- 
marabb max(7, 8) - 8 hét alatt érhető el. Hasonlóan kapjuk, 
hogy az E-be leghamarabb max(8--1, 2-3) - 9 hét munka 
árán juthatunk el. Lássuk, melyik az a tevékenységsorozat, 
amely igényli ezt a 9 hetet: 





E A kritikus út 


A fenti ábrán vastag vonallal megjelöltem azon tevékenysége- 
ket, amelyek kitöltik a 9 hetet. Ezek közül bármelyik csúszik 
is, az az egész folyamat késését jelenti. Például ha a CD te- 
vékenység 6 helyett 7 hét alatt készül el, az azt jelenti, hogy 
a teljes folyamat minimális időigénye 10 hétre nő. Az ilyen 
tulajdonságú tevékenységek sorozatát kritikus útnak nevez- 
zük (a fenti ábrán ezt húztam ki vastag vonallal). 

Azon tevékenységek késése, amelyek nincsenek a kritikus 
úton, nem feltétlenül okozza az egész folyamat késését. A 
C3E tevékenység például mindaddig nem okoz fennakadáso- 
kat, amíg az A2C3E út hossza a kritikus út hosszánál kisebb 
marad. 


Ez a tervezési módszer többféleképp használható. Egyik meg- 
közelítés az, amikor az elvégzendő tevékenységek ismertek, 
és azt szeretnénk megtudni, mennyi idő alatt végezhetünk ve- 
lük. Ebben az esetben felrajzoljuk a folyamat fenti diagramját, 
és a kritikus út megkeresésével becsülhetjük a szükséges idő- 
tartamot. 

A másik megközelítés, amelyet már említettem, szintén sok- 
szor előfordul a gyakorlatban: az időkorlát ismert (vagyis a 
kritikus út hossza), és az ebbe beleférő tevékenységek lehető 
legbővebb halmazát keressük. Ennek módja a következő: el- 
ső megközelítésben felveszünk minden tevékenységet, ame- 
lyet szeretnénk megvalósítani, az időkorlát figyelembe vétele 
nélkül. A diagramon megkeressük a kritikus utat, ez alapján 
megkapjuk, mennyi lenne a szükséges idő ebben az esetben. 
Ha ez az idő nem nagyobb a rendelkezésre álló hetek számá- 
nál, készen is vagyunk, hiszen beleférünk a keretbe. 

A probléma akkor kezdődik, ha le kell faragni az időből, hi- 





szen túllépnénk a korlátokat. Ekkor egyrészt elkezd- 
hetünk alkudozni a megrendelővel, viszont ő több- 
nyire hajthatatlan. Nem marad más, mint a tevé- 
kenységekből lefaragni. Mivel a kritikus út az, ami 
alsó határt szab a szükséges időtartamnak, e mentén 
kell , visszafogni" magunkat, azaz valamely tevékenységet 
vagy teljes egészében csökkenteni, vagy másik, kevesebb 
funkcionalitást megvalósító, de kevesebb időt is igénylő 
feladattal helyettesíteni. Ekkor a módosított gráfon újra meg 
kell keresni a kritikus utat, majd ezt vizsgálva (belefér-e az 
időkorlátba) a fenti műveleteket mindaddig folytatni, amíg 
megfelelő eredményt nem kapunk. A tevékenységek által ek- 
kor megvalósított funkcióhalmaz lesz az, amely belefér a 
meghatározott időkeretbe. 


Természetesen vannak még más módjai is annak, hogy időt 
takarítsunk meg. Egyrészt elképzelhető, hogy újabb emberek 
bevonásával gyorsabban halad a fejlesztés. Ezzel azonban 
óvatosan kell bánni, hiszen ha az új emberek képzettsége 
nem a megfelelő, többet veszítünk a képzésükkel és felzár- 
kóztatásukkal, mint amennyit nyerünk az általuk elvégzett 
munkával. A másik szempont, amelyet újabb erőforrások ese- 
tén figyelembe kell venni, hogy több erőforrás több pénzbe is 
kerül. Meg kell tehát találni az idő, a pénz és az elvégzett 
munka optimumát, azonban arra is figyelni kell, hogy a 
feladatok nem párhuzamosíthatók a végtelenségig. (Ha egy 
nő kilenc hónap ,munka" után szül meg egy kisbabát, kilenc 
nő nem képes ugyanerre egyetlen hónap alatt...) 

Az is lehetséges, hogy az emberek átcsoportosításával, a 
feladatok más leosztásával optimálisabb időbeosztáshoz ju- 
tunk. Nagyon triviálisnak tűnő dolgok ezek, de nagyon sok- 
szor látni, hogy vezető beosztású emberek nem veszik figye- 
lembe dolgozóik személyes adottságait: a jó adatbázisfejlesz- 
tőt beosztják kliensoldali alkalmazás fejlesztésére, a web- 
designert tárolt eljárások írására stb. 


Egyik nagy tiszteletnek örvendő tanárom, Prónay Gábor ha- 
sonlata rendkívül találó: tegyük fel, hogy van lehetőségünk 
összeszedni a világ legjobb focistáit, és egy csapatba összeál- 
lítani őket: a legjobb csatárt, a legjobb kapust, a legjobb hát- 
védet stb. Azt feltételezzük, hogy ekkor a világ legjobb foci- 
csapatát kapjuk. Ha viszont a játékosokat mind egy kicsit más 
helyre állítjuk a pályán, mint amiben a legjobbak (a csatárt 
kapusnak, a kapust hátvédnek stb.), az eredmény siralmassá 
válik. 


Az időgazdálkodáshoz fontos szempont még a megfelelő 
technológia kiválasztása is. Ezt nem csupán a megrendelő 
pénztárcájához, hanem saját erőforrásainkhoz is igazítani 
kell: ha például cégünk mindeddig Java és PHP programok 
fejlesztésével foglalkozott, és most egy .NET alkalmazást vár- 
nak tőlünk, kellő időt kell hagyni a képzésre, tanulásra is, hi- 
szen az ,in medias res" beleugrás a fejlesztésbe nem szokott 
sikerre vezetni. 


A fejlesztési folyamat tervezésekor figyelembe kell vennünk a 
rendszer más rendszerekkel való kapcsolatát is, hiszen egyre 
több az integrált szoftvert, új programunk nem önállóan fog 
működni, hanem a vállalat egyéb folyamatival összhangban. 
Nem mindegy tehát, mi van körülöttünk. Ehhez ismét a vevő 
nagyfokú közreműködése szükséges. 

Lássunk itt is egy példát. Tegyük fel, hogy piskótasütő robo- 
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tunkat olyan környezetben kívánjuk elhelyezni, 
ahol más robotok is dolgoznak. Az egyszerűség ked- 
véért legyen ez egyetlen szakácsrobot. Ha a két ro- 
botot két különböző cég fejleszti, és nem tudnak 
egymásról, nyilvánvalóan nem is merül fel annak 
gondolata, hogy munkájukat például össze is kell szinkroni- 
zálni. Érdekes eredményeket produkálhatunk például, ha a 
piskótatésztába beletesszük a sütnivaló csirkét, vagy egyik ro- 
bot 180, a másik pedig 300 fokra állítja a sütő hőmérsékletét. 
A hétköznapi életre átfogalmazva tehát ügyelni kell a közösen 
használt erőforrások (adatbázisok, nyomtatók, stb.) megfelelő 
szinkronizációjára. 

Másik probléma lehet az integrációnál, ha a két rendszernek 
együtt kell működnie, például egymástól kapnak adatokat, 
esetleg utasításokat is. Ilyenkor a rendszerek közötti kommu- 
nikáció biztosítására megfelelő interfészt kell biztosítanunk 
egymás irányába. Ha például a piskóta tetejére csokimázt 
szeretnénk önteni, és ezt egy másik robot készíti, annak min- 
denképp tudnia kell az aktuális piskótalap méretét, vastagsá- 
gát stb., hogy ahhoz tudja igazítani a keverendő máz mennyi- 
ségét. 


A való életben itt is előjöhetnek egyéb, nem szakmai jellegű 
problémák is. Előfordulhat, hogy egy üzleti döntés értelmé- 
ben két vagy több rendszert egyidőben szeretnének bevezet- 
ni. Ilyenkor egy-egy határidő módosítása több másik határidő 
módosítását is maga után vonhatja, hiszen ha a rendszerek 
közül akár csak egy is késik, az felborítja az egész átadási fo- 
lyamatot. 

Ezért rendkívül fontos, hogy amennyiben más rendszerektől is 
függünk, pontosan tisztában legyünk minden olyan tényező- 
vel, amely akár a legkisebb mértékben is befolyásolja projek- 
tünk sikerességét. 


Ha mégis hiba csúszik be... 


Mi történik akkor, ha minden elővigyázatosságunk ellenére 
csúsznak az egyes fázisok, és késik a végtermék? 

Talán ezt a legnehezebb megmondani. Először is amint prog- 
nosztizáljuk a késés lehetőségét, el kell ismernünk azt, és 


nem a csodára várnunk, bízva abban, hogy valami történik, 
aminek következtében mégis készen leszünk határidőre. 
Késés esetén alapvetően két lehetőség közül választhatunk. 
Egyrészt igyekezhetünk megvalósítani mégis minden funk- 
ciót, kevésbé kitesztelve, kevésbé odafigyelve a minőségre, 
hiszen még így is van esélye annak, hogy helyesen fog mű- 
ködni. 

A másik taktika, hogy tovább szűrjük a funkciókat (a megren- 
delővel közösen), és csak annyit valósítunk meg, amennyit 
biztonsággal be tudunk vállalni, azaz amelyek esetében biz- 
tosan nem következik be minőségromlás. Gondolom, nem 
kell ecsetelnem, miért célszerű ez utóbbi lehetőséget válasz- 
tani... 

A harmadik lehetőség a határidő közös, a vevővel egyeztetett 
módosítása. Előfordulhat, hogy bár a projekt elején ragaszko- 
dott a 6 hónaphoz, azóta mégis történtek olyan változások, 
amelyek alapján a 7 hónap is elfogadható számára, vagy eset- 
leg a rendszer fejlesztése közben rálátott arra, hogy milyen 
alaposan, színvonalasan dolgozunk, és látja, nem jár rosszul, 
ha rááldozza még azt a plusz időtartamot. 


Ezek azonban már nem szorosan informatikai, sokkal inkább 
menedzsmentkérdések. Ahhoz azonban, hogy egy fejlesztési 
folyamatot sikeresen le tudjunk vezényelni, nem elég a fej- 
lesztéshez érteni, a feladat sokkal összetettebb. Egy kicsit fej- 
lesztőnek, kicsit menedzsernek, kicsit pszichológusnak és 
szociológusnak is lennünk kell egyszerre, ez azonban nem 
könnyű feladat. 


Az élet viszont azt igazolja, hogy nem is lehetetlen... o 


Molnár Ágnes 
Molnar. AgnesGcleware.hu 
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XMLA és ADO MD .NET előzetes 


Az MS SOL Server 2000 egyik újdonsága volt, hogy támogatta a relációs adatbázisaiban tárolt adatok 
elérését XML segítségével. Az ADO.NET-tel a relációs adatok és az XML fogalma még jobban összefo- 
nódott. De mi van az Analysis Serverben tárolt régi jó adatkockáinkkal és adatbányász modelljeinkkel? 
EI tudjuk-e érni őket a .NET, vagy XML segítségével? Ezt fogjuk most megvizsgálni. 


Mire nem jó az ADO.NET? 


Számtalan hasznos és érdekes cikk jelent már meg e magazin 
hasábjain az SOL Server 2000-rel kapcsolatban. Azonban 
ezek a cikkek szinte kivétel nélkül a relációs adatbázismotor- 
hoz kapcsolódó témákkal foglalkoztak. Ahogy a világban sem 
minden szögletes (hajrá kerek formák), az SOL Server 2000 
adatbázisai közül sem minden relációs. Ez a másik világ a 
többdimenziós adatbázisok csodálatos világa. 

Hol is rejtőznek ezek az adatbázisok? A választ az SOL 
Server konferenciákra járó kedves olvasó is bizonyára jól 
tudja, hogy a többdimenziós adatbázisainkat az Analysis 
Server rejti. Elevenítsük csak fel, hogy mi is van ezekben az 
adatbázisokban? A konferencialátogatók már tudják, hogy 
csupa fontos információt tartalmazó válaszok: 

1 Mely termékek hozzák a legtöbb profitot az egyes ér- 
tékesítési régiókban? 

mM Milyen szezonalitás figyelhető meg az egyes termé- 
kek esetében? 

H Ha továbbra is ilyen ütemben bővül a piac, akkor vár- 
hatóan jövőre kinek, miből mennyit fogunk értékesí- 
teni? 

A Mi jellemzi a tipikus fogyasztónkat, milyenek a vásár- 
lási szokásai? 

mM A régi ügyfeleink közül a piaci verseny élesedésével 
kiket tud elcsábítani a konkurencia? 


Ugye fontosak ezek az információk? De hogyan érhetjük el 
őket? Simán, vághatnánk rá kapásból. Van nekünk egy gyö- 
nyörűséges ADO.NET-ünk, amivel olyan egyszerűen érjük el 
az SOL Serverben levő adatbázisainkat, hogy öröm nézni, és 
tuti, hogy vannak benne olyan osztályok is, amelyekkel gye- 
rekjáték a többdimenziós adatok elérése. Ki tudja megmutat- 
ni, hogy melyek is ezek az osztályok? (Segítségként elárulom, 
hogy az ADO.NET osztályokat az XML-es osztályokkal együtt 
a legkisebb poszteren találhatjuk.) 

A kérdés bizony beugratós volt. A többdimenziós adatbázis- 
szerver már a 7-es verziójú SOL Serverben 1998-ban megje- 
lent (akkor még OLAP Servernek hívták, a 2000-es továbbfej- 
lesztett verzióban Analysis Serverre keresztelték át a fejlesztői, 
köszönhetően az adatbányász kiegészítéseknek), azonban 
ADO.NET-tel csak a relációs adatbázisainkat tudjuk elérni. 
(Ha valaki mégis rálelne ezekre az osztályokra, kérem szóljon, 
mert akkor én egy nyomdahibás posztert kaptam. 0) 

Akkor most mit tegyünk? Töröljük le az Analysis Servert és 
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kerek formák], az 


mindent, ami rá emlékeztet? Eszünkbe ne jusson!! Már látszik 
a fény az alagút végén, jön az ADO MD .NET. 


ADO MD .NET, hát az meg mi a szösz? 

Akik figyelmesen átolvasták az ADO (ActiveX Data Objects) 

dokumentációt, azoknak észre kellett venniük a dokumentá- 
cióban szereplő ADO MD-t is. De mit 
is jelent a végén az MD és mire jó? Az 


Ahogy a világban MD a Multi Dimensional, azaz több- 
dimenziós rövidítése és az Analysis 
sem minden Serverben levő adatbázisaink sémáját 


és a sémában tárolt adatainkat tudjuk 
vele lekérdezni. Csak lekérdezni, 
ugyanis a séma felépítésére, illetve 
módosítására a DSO (Decision 
Support Objects) használható. Az 


szögletes [hajrá 


SOL Server 1000 ADO MD dokumentációja az [1] cí- 
men, a DSO használatát bemutató 

adatbázisai közül cikkek pedig a [2] és [3] címen érhe- 
tőek el. 

sem minden Mind az ADO MD, mind a DSO a 


.NET előtti COM komponensek vilá- 
gából származik, menedzselt kódból 
eddig csak COM interop segítségével 


relációs. Ez a másik 


világ a többdimen- használhattuk őket. 
Néhány hete, 2003 augusztus elején 
ziús adatbázisok jelent meg az Interneten az ADO MD 
.NET bétaváltozata, jelezve, hogy az 
ADO MD sem marad ki a .NET- 


csodálatos világa. 


szi esítésből. A [4] címről a szoftverfej- 


lesztői készletet (SDK), az [5] címről 
pedig a dokumentációt lehet letölteni. A béta változatot jelzi, 
hogy sajnos még önállóan nem tud megállni a lábán, előtte fel 
kell telepíteni az XML for Analysis (XMLA) 1.1-es (szintén bé- 
ta) verzióját, ami a [6] címen érhető el. 


XMLA röviden 


Az XML for Analysis szabványtervezet a Microsoft és az 
Essbase, illetve az időközben hozzájuk csatlakozott cégek el- 
képzelése arról, hogy hogyan lehetne egységes módon elérni 
a többdimenziós adatbázisokat. A kezdeményezésről és a 
résztvevőkről további információk a [7] címen olvashatók. 

Az első verzió 2001 áprilisában jelent meg, segítségével 
SOAP borítékokon (Simple Object Access Protocoll, XML for- 
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mátumú kommunikáció szabványos HTTP protokol- 
lon) keresztül tudtuk elérni a kiszolgálóra telepített 
XMLA szolgáltató (provider) metódusait, ha ismerjük 
a szolgáltató URL-jét. 


XMLA bővebben 


Nézzük is meg kicsit részletesebben, hogy mi is került az 1.1- 
es telepítőkészletbe. Alapértelmezés szerint csak a biztonsá- 
gos HTTPS protokollon keresztül érjük el az adatainkat. A 
HTTP protokollt a telepítés során külön engedélyeznünk kell! 
A telepítés során, ha nem változtatunk rajta, a következő hely- 
re települnek a komponensek: 





Sti 


A működéshez azonban még néhány lépést el kell végezni. 
Először is olvassuk el a readme.htm-et, ahonnan megtudhat- 
juk, hogyan állíthatjuk be az adatforrásunkat és az 
msxisapi.dil-t tartalmazó virtuális könyvtárunkat, aminek a 
nevére nem adnak ajánlást, de a példaprogramok xmla néven 
hivatkoznak rá. Dönthetünk persze más név mellett is, ebben 
az esetben viszont át kell írni a hivatkozásokat. 


elj 
What.XML for Analysis service do you want to use? ! 
URL: fhttp://ocalhostZamla/msxisapidi 7 Update 
DES S elSáG  VSÁSÉ SE SEEN] 





a Az msxisapi.dil-t az xmla virtuális könyvtárba tegyük, 
vagy írjuk át az elérési utat 


A Help könyvtárban találhatunk egy elég jó súgót, amiből az 
is megtudhatjuk, hogy a Samples könyvtárban három egész 
példaprogram azt várja, hogy kipróbáljuk: 
A Sample: A sokat próbált MDX Sample nevű ADO MD- 
s példaalkalmazás átírása XMLA-ra. 
HA Sample.NET: Ez is az MDX Sample alkalmazás VB 
. NET-es átírása XMLA-val. 
A Simple: Egyszerű, de nagyszerű példaprogram az adat- 
bázis sémájának és a benne tárolt adatok lekérdezésé- 
re. A megjelenítés lehet XML és HTML alapú is. 


A .NET-es példa elindításához szükségünk van VB 6-os kom- 
ponensek regisztrálásához is. Ebben az esetben a 318579-es 
számú Tudásbázis cikk írja le a megoldást. Már csak egy apró 
problémánk lehet, megtalálni a hiányzó Mdxguery.xml nevű 
fájlt a mintalekérdezésekkel. Ezt a fájlt a Sample nevű példa- 
program könyvtárában találjuk. 


De mitől mozog? 


A példák kipróbálása után nézzük is meg, mi van a mélyben, 
mitől is működnek. A fő mozgatórugó az xmla virtuális könyv- 
tárban lévő XMLA szolgáltató. A szolgáltatót HTTP protokol- 
lon keresztül elküldött SOAP borítékba csomagolt XML alapú 
kérésekkel szólíthatjuk meg. A megszólítás vonatkozhat az 
adatbázis sémájára, ekkor a Discover metóduson keresztül, il- 
letve többdimenziós lekérdezések végrehajtására, ekkor pedig 
az Execute metóduson keresztül kaphatjuk meg az igényelt in- 
formációt, természetesen SOAP borítékba csomagolva. 






































E Adatbázisok elérése XMLA segítségével 


Miután a Discover metódussal felderítettük az elérhető adat- 
bázisokat, adatkockákat, dimenziókat, adatbányász modelle- 
ket, az Execute metódussal le tudjuk futtatni az MDX-ben 
(MultiDimensional eXpression) megfogalmazott lekérdezése- 
ket. Az MDX a többdimenziós adatbázisok lekérdező nyelve. 
Szintaktikáját tekintve annyiban hasonlít a relációs adatbázi- 
sok lekérdezésére használt SELECT utasításra, hogy itt is van 
FROM és WHERE záradék, azonban el is tér tőle, mert több- 
dimenziós és adatbányászati adatok lekérdezésére alkalmas. 
Az MDX-ről rövid ismertető a [8] címen, az SOL és az MDX 
rövid összehasonlítása a [9] címen érhető el. 
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EB Egyszerű példák a sémák és az adatok lekérdezésére 


Az XMLA egy remek megoldás de azért csak kényelmesebb 
lenne egy objektummodellen keresztül elérni az adatokat. 


ADO MD .NET 


A hiányzó objektummodellt az ADO MD .NET fogja szolgál- 
tatni, egyelőre úgy, hogy a háttérben XMLA-n keresztül kom- 
munikál a kiszolgálóval. Az — objektummodellt a 
Microsoft.AnalysisServices.AdomdClient névtérben találhat- 
juk meg. A névtér legfontosabb objektumai: 

HA ADOMDCOnnection: Segítségével a kiszolgálón talál- 
ható adatbázisokhoz, vagy a helyi .cub kiterjesztésű 
kockafájlokhoz kapcsolódhatunk. A kockafájlokba az 
adatbázisunk egy részét tudjuk exportálni. 

H ADOMDCommand: MDX lekérdezések lefuttatására 
alkalmas, ADOMDDataReader vagy Cellset objektum- 
mal tér vissza. 

A ADOMDDataReader: MDX lekérdezés eredményét ad- 
ja vissza táblázatos formában; csak előrefele olvashat- 
juk. 

A CellSet: Szintén MDX lekérdezés eredményét tartal- 
mazza, de lassabb, mint az ADOMDDataReader, vi- 
szont előre és hátra is navigálhatunk az adatokon és a 
metaadatokon. 

A CubeDef: Az elérhető adatkockák felépítéséről kapha- 
tunk információkat 


Sajnos a fejlesztők elfelejtettek példaprogramot mellékelni a 
telepítőcsomaghoz, meghagyva a felfedezés örömét az el- 
szántságot érző vállalkozóknak. Remélhetőleg a végleges vál- 
tozat kibocsátásakor nem lesznek ilyen feledékenyek. 


Homokszemcse a gépezetben 


Az XMLA SDK-hoz példaként kapott programok nem tökéle- 
tesek. Mindkét Sample nevű példaprogram ugyanazt az apró 
hibát tartalmazza. Ha a Foodmart 2000 adatbázisban a követ- 
kező lekérdezést lefuttatjuk, eredményül nullával való osztási 
hibát kapunk. 


A hiba a megjelenítési részben van: az frmXmlAnalysis 569-es 
sorából hiányzik egy 0-val való ellenőrzés. A hibát okozó sor 
és az utána következő négy sor az Else ágba került. 





A Sample.NET példa esetében az frmXmlAnalysis.vb 1114-es 
sorához szintén kívánkozik az előbbi ellenőrzés, de itt az If 
ágban a következő kód szerepeljen: 





Szép új világ 


Nem kell már objektummodell nélkül álomra hajtani a fejüket 
azoknak, akik az Analysis Serverben tárolt adataikból szeret- 
nének jelentéseket készíteni a fontos üzleti döntéseik megho- 
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zatalához. A.NET-hez felnőtt ADO MD-vel most már 
nemcsak a relációs adatokat, hanem a relációstól el- 
térő módon tárolt többdimenziós és adatbányász 
adatainkat is könnyen és egyszerűen nyerhetjük ki 
az SOL Server adatbázisaiból. 

Remélhetőleg az ADO MD .NET a .NET keretrendszer 2.0-ás 
— az SOL Serverrel szorosan integrált (bővebben a [12] címen) 
— következő verziójában már mindenki régi ismerősként fog 
visszaköszönni. 


Hasznos holmik 


Aki nem ismerné a cikkben szereplő .NET-es technológiákat, 
azoknak ajánlanám a Technet Magazin korábbi számait és a 
[10] címen található oldalt, ahol regisztráció után ingyenes, 
magyar nyelvű oktatóanyagokat igényelhet. 

Az Analysis Serverrel most ismerkedőknek ajánlom az 
Analysis Manager elindítása után a jobb oldali ablakban a kis 
zöld könyvecske mellett megjelenő Analysis Manager 
Concepts £ Tutorial-ban levő gyakorlatokat, a Books Online-t 
és az SOL Server 2000 Resource Kit-et [11]. 


Hangyál Zoltán 
hangyal€novosys.hu 


A cikkben szereplő URL-e 


(1) http://msdn.microsoft.com/library/en-us/ado270/htm/ 
"adomdo01.asp 

[2] http://msdn.microsoft.com/library/en-us/olapdmpr/ 
"Wprabout 84a4.asp 

[3] http://msdn.microsoft.com/library/en-us/dnsgl2k/html/ 
"dsosgl.asp 

[4] http:/Avww.microsoft.com/downloads/details.aspx? 

4 familyid-49737737-681e-465e-83c5-51b7223b1585 
[5] http:/Awvww.microsoft.com/downloads/details.aspx? 

$ familyid-D4DDB8A54-F43A-4D93-A099-f 3FBFT17BFIDB 
16] http://www.microsoft.com/downloads/details.aspx? 

$ familyid-O2DDCCBO-604B-4343-9D42-4298E10A1A56 
[7] http:/Awww.xmla.org 

[8] http://msdn.microsoft.com/library/en-us/dnolap/html/ 
"intromdx.asp 

(9] http://msdn.microsoft.com/library/en-us/olapdmad/ 
"tagmdxbasics 90gg.asp 

[10] http://www.developer.hu 

[11] http://www.microsoft.com/technet/prodtechnol/sgl/ 
"reskit/sg12000/sal2krk.asp 

[12] http://www.microsoft.com/hun/net/Roadmap.asp 
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Reguláris kifejezések 


3b 


regexekkel 


keguláris kifejezések 


Szövegfeldolgozás elmélet és gyakorlat 


A szövegekben keresés, egyes részek cseréje, kiemelése már az informatika kezdete óta foglalkoztat- 
ja a szakembereket. A regexek segítségével rendkívül kifejező módon tudunk részleteket megfogni 


egy hosszabb és nem szigorúan szabályos szövegből is. Ennek elméleti és gyakorlati kérdéseit bon- 


colgatjuk a következő kilenc oldalban. 


Regex történelem 


Reguláris kifejezés, angolul Regular Expression. Eredetileg a 
neuronfiziológiában vezették be ezt a fogalmat az 1940-es 
években. Éredekes nem, hisz akkor hol voltak még a maihoz 
hasonló számítógépek? Aztán jópár évvel később Stephen 
Kleene kitalálta a Reguláris Halmazokat mint matematikai el- 
méletet, és ehhez vezetett be egy jelölésmódot, amit Regular 
Expression-nek hívott. Akit érdekelnek a matematikai részle- 
tek (engem nem), annak itt a referencia: Robert L. Constable, 
"The Role of Finite Automata in the Development of Modern 
Computing Theory," in The Kleene Symposium, eds. Barwise, 
Keisler, and Kunen (North-Holland Publishing Company, 
1980). 

A regexek első gyakorlati felhasználása Ken Thompson nevé- 
hez fűződik (remélem nem kell bemutatnom, ha igen, akkor 
sürgősen do google!), aki ,Regular Expression Search 
Algorithm" című cikkében vezeti be a reguláris kifejezések 
használatát szövegfeldolgozásra. 

Ő írta meg a ged nevű szövegszerkesztőt, ami a Unixon jól is- 
mert ed kifejlődéséhez vezetett. Ezekben a szövegszerkesz- 
tőkben már volt regex kiértékelő, így lehetővé vált bonyolul- 
tabb szövegrészek megtalálása és cseréje is. 

Az ednek volt egy parancssori eszköze, ami szövegfájlok so- 
raira egyező reguláris kifejezéseket nyomtatott ki. Ez volt a 
, Global Regular Expression Print", rövidítve grep. Bízom ben- 
ne, hogy nem Unixon felnőtt programozók is hallottak erről a 
programról. 

Ezek a kezdeti programok persze még sokkal egyszerűbb re- 
guláris kifejezéseket ismertek, mint a mai értelmezők, de (mint 
minden fejlődés ebben a szakmában) a regexek is iteratív mó- 
don fejlődtek. 

Ezután jött a jóval több metakaraktert használó egrep, ami 
már teljesen más elven működött, mint elődje. A grep 
Deterministic Finite Automat-ot (DFA) használt, míg az egrep 
Nondeterministic Finite Automat-ot (NFA). Egyszerűen megfo- 
galmazva a DFA gyors, de butább, az NFA egyes esetekben 
rettentő lassú, de sokkalta okosabb, és szabadságot ad a 
regexeken keresztül a motor közvetlenebb vezérlésére. A mai 
regex motorok zöme NFA. 


Majd jött a sed, az awk, a lex, amelyek mind valamilyen 
szempontból továbbfejlesztették a regexek nyelvtanát. A sok- 
féle nyelvjárás között a POSIX szabvány próbált rendet rakni. 
Legfőbb előnye, hogy bevezette a locale fogalmát, így a betű 


végre nem csak az angol ABC karaktereit jelentette. Mi ma- 
gyarok ismerjük a szakmában az ,angol diszkriminácót", így 
örülünk a Posix törekvéseinek. 

Napjainkban a Perl az a környezet, amely a reguláris kifejezé- 
sek használatában és újításokban a fő húzóerő. A példákban a 
.NET Framework regex osztályait használjuk, amelyeket a Perl 
5 regexei alapján modelleztek, így nagyon magasszintű regex 
támogatást kapunk. 


Bevezetés 


A regex a reguláris kifejezés rövidítése. A cikkünkben tárgyalt 
szövegeket bogarászó regexek már szokszor nem regulárisak 
matematikai értelemben, ezért általában egyszerűen 


regexként hivatkozunk rájuk, megkülönöztetve őket a mate- 
matikai reguláris kifejezésektől. 

Nos, mi is az a regex? Egy olyan leíró nyelv, amely segítségé- 
vel szövegek különböző részeit ragadhatjuk meg, írhatjuk le. 
Gondoljunk a fájlrendszerre: 





Bevezettünk egy metakaraktert, a "-ot (csillagot), amit úgy de- 
finiáltunk, hogy egyezik bármilyen fájlnévre. Nos, a regexek 
hasonlóak, csak sokkal több metakarakter található bennük, 
így sokkal gazdagabban fogalmazhatjuk meg az illesztendő 
szöveget. 

Kiinduló példánk a következő lesz. Szeretnénk egy szövegben 
megkeresni a dadogásokat dadogásokat. Gyakori szövegszer- 
kesztési hiba az ismétlés, ezt kellene megkeresni egy tetszőle- 
ges szövegben. Azt gondolnánk, minek ide regex, sima 
sztringkezelő eszközökkel is megoldható a probléma. 
Például feldarabolhatnánk a szöveget szavakra (whitespace- 
ek mentén), majd végigmenve a listán összehasonlítjuk az 
egymás után következő szavakat. Ha egyeznek, ismétlést ta- 
láltunk. 

Igen ám de lehet, hogy a szavakat markup tagok határolják, 
mint pl. egy html szövegben: 





Ebben az esetben is meg kell találni az ismétlődő szavakat. 
Természtesen ez és minden más probléma is megoldható 
alapvető sztringműveletekkel (Find, Split, Replace), de sok- 
szor egy regexes megoldás sokkal egyszerűbb lesz. 

A problémát megoldó regex így néz ki: 





A regex csak a nyilak közötti rész, de a nyilakat mindig kiírom 
mind a szövegekben mind a kódblokkban, hogy jelezzem ha 
regexről beszélünk. A cikk célja, hogy a végére mindenki szá- 
mára magától értetődő legyen ez a regex. 


Karakteregyezések 


Egy karakter saját magával mutat egyezést, ha nem vezérlőka- 
rakter. A példákban az egyezéseket mindig aláhúzással jelö- 
löm. Ahol fontos, ott kiírom, hány egyezést találna a regex 


a 
a 
o 
H 


- gasazalapta szielnbag , 9doTana 


A legtöbb regex motor átkapcsolható kis-negybetűre nem 
érzékeny módra, ilyenkor értelemszerűen alakulnak az egye- 
zések. .NET-ben ez a RegexOption.IgnoreCase opcióval ér- 


se 
a 
Or 
e 


Karakterhalmaz egyezések 


Egy karakterhalmaz egyezést mutat ugyanazzal a karakterhal- 
mazzal, szóhatártól függetlenül. 
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A regexekben minden karakter számít, még a whitespacek is. 


a 


e 


Ez fontos, mert sokszor hajlamosak vagyunk egy bonyolultabb 
regexet picit szellősebbé tenni szóközökkel, ám ettől megvál- 
tozik a regex viselkedése. 

Egyes regex implementációkban, mint a Perl vagy a .NET, le- 
hetőség van whitespace-ek és kommentek használatára a 
regexekben. .NET-ben a RegexOptions.IgnorePatternwWhite- 
space opció után a whitespace-ek nem számítanak a 
patternben, és tt után még megjegyzéseket is lehet fűzni a s0- 
rokhoz. De akkor ebben az esetben hogyan írjuk le a 
whitespace-eket? Hasonlóan, mint a legtöbb stringet feldolgo- 
zó programnyelven: escape szekvenciákkal. A következő táb- 
lázatban megtekinthetjük a legfontosabb (de nem az összes) 
helyettesítő karaktert. 


tech.net Wat Eda sg with 


Leírás 


Karakter 

















Közönséges Mind, kivéve . $AT[(0)84?N 

karakterek 

b Visszatörlés (backspace) Vu0008 ha [] 
karakterosztályban van, egyébként 
szóhatár (ezekről bővebben kicsit 
később) 

u Tab 410009. 

wr Kocsivissza MUO0OD. 

mr Újsor karakter Nu000A. 

x20 Egy ASCII karakter hexa kóddal, 


pontosan két digiten leírva. 
Ez pl. egy szóköz. 

ec ASCII vezérlőkarakter (32-nél kisebb 
kódú karakter), ez pl. a CTRL-C 











140170 Egy Unicode karakter, pontosan négy 
hexa számjeggyel leírva, ez egy nagy 

se Ő betű K S 
N Ha nem escape-elt karakter előtt van, 


akkor egyszerűen elhagyásra kerül, 
így marad a mögötte levő karakter. 
Pl. Mg egyszerűen egy Mg betű. 





A Vuxxxx hexa szám a karakter ún. code pointja az unicode 
táblázatban, nevezzük egyszerűen karakterkódnak. Látható, 
hogy ezt a jelölést nyugodtan lehet használni regexekben, így 
biztos nem fürdünk be a sunyiban o betűvé átkonvertálódott 
ő betűkkel (a szövegszerkesztők miatt). A kódokat leg- 
egyszerűbben a Windows Character Map-ban találhatjuk 
meg. 

A visszafele perjel (V beírásához duplázni kell (4. 


Karakterosztályok 


Eddig csak konkrét karakteregyezéseket vizsgáltunk meg. Az 
f betű az f-fel egyezik, kész. Természetesen lehet használni 
olyan konstrukciókat, amelyek több mint egyféle karakterrel 
egyeznek, ezek a karakterosztályok. 

Karakterosztályokat 2 (...1€- (szögletes zárójelek) között lehet 
definiálni. Az osztályban felsorolt bármelyik karakter szere- 
pelhet az egyezésben, de nagyon fontos, hogy pontosan 
egyetlen karaktert helyettesít egy karakterosztály kifejezés, 
nem többet. 


Látható, hogy a 2Írsk]€ jelentése: egy karakter, ami r vagy s 
vagy k lehet. 


A 310123456789]€- bármilyen decimális számjegyre illesz- 
kedik, ezért 8 ponton egyezik a második sor tesztszövegével. 
Karaktertartományokat is megadhatunk karakterosztályokban 
— (mínusz)-szal elválasztva, így nem kell felsorolni minden 
egyes karaktert. 

Ez a példa egzaktul azonos az előzővel, csak rövidebb: 
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7 


A következő regexet így kell értelmezni: bárhol a 
szövegben egy decimális számjegy, amit egy deci- 
mális számjegy követ. Lehet, hogy így túl analitiku- 
san hangzik, de bonyolultabb regexeknél a túl intui- 
tív, ,belelátom én mit csinál egyszuszra" gondolko- 
dásmód gyakran tévútra csal. 


ma 


3[0-9][0-9]1€ 
Született: 1492. 08. 12. - 4 egyezés! 


Karakterosztályon kívül a - jel közönséges karakter: 


SZOESTTOSSAG€ 
Született: 1492-08-12. - 2 egyezés! 


Érdemes odafigyelni, hogy sok karakter másképp viselkedik 
karakterosztályon kívül és belül. De ez még nem minden! 

A - jel karakterosztály elején és végén közönséges karakter. 
Nézzük kontrasztba állítva. Ebben a példában a regex a a-tól 
27-ig terjedő karaktert tartomány jelöli ki: 


73 [a-zi€ 
g - d - 2 egyezés 


Itt viszont az első mínusz közönséges karakter: 


2I[-a-z1€ 
c - d - 3 egyezés 


Karakterosztályon belül az utolsó pozíción is közön$éges ka- 
rakter lenne, így az 2 [a-z-1€- azonos a fenti regexel. 

Egy karakterosztályban több tartomány és karakter is felsorol- 
ható vegyesen is. Például: 


3Ieza0-2]€ 

Született: 1975-01-10 - 8 egyezés 
70x[0-9abcdefABCDEF)] [0-9gabcdefABCDEF] € 

0x15, OxaF, 0x5H, 0x1B, hexa számok - 3 egyezés 


Gyakran egyszerűbb megfogalmazni úgy egy karakterhal- 
mazt, hogy bármilyen karakter, kivéve ezt és ezt. Erre való a 
negált karakterosztály. A jelölésmódja egy " (kalap) a karak- 
terosztályt jelölő [ (nyitó szögletes zárójel) után közvetlenül. A 
következő példa jelentése: bármilyen karakter, kivéve a 0-9-ig 
terjedő tartományt, magyarul bármi, ami nem szám: 


3150-91€ 
Született: 1492. 08. 12. - 16 egyezés 
Nem első pozíción már közönséges karakter a ?: 


3I[0-91e]€ 


Született: 1492. 08.A 12. - 12 egyezés 


Előre definiált karakterosztályok 


Vannak gyakori esetek, amelyeket nem fontos hosszan karak- 
terosztályként definiálni, hanem vannak előre elkészített rövi- 
dítések rájuk. 


Gyakran kell a 210-9]€- karakteroszályt használni, amit a 
73)d€ helyettesíthet. A következő példa négy egymás utáni 
számjegyre ad egyezést. Figyelem! Nem négydigites számokat 
keres! Mint már tudjuk, az egyezések függetlenek a hétközna- 
pi értelemben vett szóhatártól, így az első hosszú számban 
három egyezés is lesz, a három egymást követő négy szám- 
jegyből álló blokk: 


7vdtatdata 


1258632455458: 1492. 08. 12. - 4 egyezés 


AND a 2190-9]€  karakterosztállyal egyezik meg, azaz nem 
számjegy. 


77 NDNDNDVDE 


Született volna: 1492. 08. 12. - 4 egyezés 


Az egyezések kifejtve: 
zs Szül 


zs etet 
zs; t vo 


4 WHO 


zs; lna: 


Sajnos az aláhúzásos jelölésmód időnként nem egyértelmű, 
ezért néha kifejtem a kimenetet. Amikor progamozzuk a 
regexeket, ebből nincs gond, mert a találatokat egy kollekció- 
ban kapjuk vissza. 

A 2Ww6- bármilyen betűt, számot vagy aláhúzásjelet ( ) je- 
lent. Nem bármilyen karaktert, hanem bármilyen betűt, be- 
leértve a gonosz őű betűket is. Pontosabban: ez attól függ. A 
.NET-es implementáció alapban minden betűt beleért, de át- 
kapcsolható ECMA módba is (RegexOptions.ECMAScript), 
ahol a 2Aw€ -- 2 [a-zA-ZO-9 ]€-. Azaz ettől kezdve csak 
az angol ABC betűivel foglalkozik, így az ékezetes betűinket 
mind kihagyná. 


Figyelem! Más implementációban lehet, hogy eleve így mű- 
ködik a regex motor, azért éles bevetés előtt mindeképpen 
tesztelni kell ékezetes betűkkel is az egyezéseket! 

Normál módban: 


2 VwNwiwt 
Született: 1492. 08. 
zs; Szü 
zs; let 
ett 
zs; 149 


12. 


WWW HO 
u 
v 


RegexOptions.ECMAScript esetén látható, hogy az ü betű 
nem tartozik bele a 24w6--be, így az első hármas betűcso- 
portot csak a ,let"-nél találja meg a motor: 


7 vwiwiwó 
Született: 
0 -5 let 
1 -5 ett 
2 zs; 149 


1492. 08. 12. 


Mi a helyzet az euro (€) karakterrel? Az betű? Egyáltalán, hol 
található ez a billentyűzeten? Nos, első körben én sem talál- 
tam. Aztán rákerestem az euro-ra az unicode.org-on [1], ahol 
találtam egy riportot [2], mely szerint az euro karakter a 2.1- 
es unicode szabványban jelent meg. Most egyébként (2003. 
október) a 4.0 unicode szabvány az aktuális. 

Nos, az euro a 20AC hexa kódot kapta. Szép, mi? Hol vannak 
már az ASCII 7 és 8 bites számokkal ábrázolt betűk! 
Kitartóbbak a Character Map-ban is megtalálhatják, legalábbis 
XP--SP1-en biztos: 


LETE ta ali 


TEJET e 


TEHTEjajMÍT TT T-[B[eo[-[- Fair 
ee te er teri tÉtÉrt te] 
ne D TT LL T[ ] 


TELTEEET] 
ETTETETETTTTT Trieirisle[e ete] 
Characters to copy: [E 


CI Advanced view 
" U5204C: Euro Sign . Keystroke: Alts0128 
B Euro szimbólum a Windows XP Character Map-ben 


Nos, a kérdés ugye az, hogy a 2w€-be beletartozik-e az 
euro? Rövid teszttel kiderül, hogy nem. Az euro szimbólum 
kategóriájú karakter, nem betű. A .NET regex motor nagyfokú 
unicode támogatást ad, így a karakterek osztályozásánál is az 
unicode szabvány által meghatározott kategóriákat használja 
[3]. Olyannyira, hogy ezt még ki is vezették nekünk. A 
3 WwlKategórianév] € kifejezéssel hivatkozhatunk a megfelelő 
kategóriába tartozó karakterekre. A kategóriák nevét a [3] táb- 
lázat tartalmazza. Nézzünk néhány érdekes példát! 





Csak meglett az euró, a pénz szimbólumok között találjuk! 
A második alkategória karaktert el lehet hagyni, így a 


3VLIE az összes betűt jelenti, amiben nincsenek benne 
a számok és az aláhúzásjel, azaz nem ugyanaz, mint a 
3weé. 

Egyébként a furcsa karakterek megkereséséhez hasznos lehet 
a Character Map Advanced nézete, amikor Unicode kategó- 
riák szerint szűrve láthatjuk a karaktereket. 
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elete etá ET 








Letterlike Symbols 
Number Forrns 

Arrows 

Mathematical Operators 
Miscellaneous Technical 























E Csak a pénzeket reprezentáló karakterek 


AWE (nagy W) minden nem betűt jelöl, azaz 29w6-. 
A 2456 bármilyen whitespace karaktert jelent. A whitespace- 
eket is az Unicode szabvány rögzíti, de leegyszerűsítve a szó- 
köz, tabulátor, kocsivissza és a soremelés tartozik bele. Van- 
nak még extra karakterek is (pl. függőleges tabulátor), de ezek 
általában nem érdekesek számunkra. A pontos lista így néz ki: 


ne JET 


A Z unicode kategória a szeparátor karaktereket jelöli, a 85 
hexa kódú karakter pedig a szóköz nem PC-s rendszerekben 
(bizarr). 








A 348€ (nagy 5) minden nem whitespace-t jelöl, azaz 
SONGS 


Az univerzális dzsóker: a pont 


A 2.€ (pont) bármilyen karakterrel egyezik kivéve az újsor 
(An) karaktert. Ha RegexOptions.Singleline módban vagyunk, 
akkor az újsorral is. 
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Normál módú viselkedés (a WWn a kocsivissza-soremelés pá- 
ros, amik nem látszanának): 


A 2$6€ (dollár) a szöveg vagy sor végét jelenti. A multiline 
ugyanúgy hat rá, mint a 29 €-ra. 





Látható, hogy az első sorban már nem volt másik 7 egybefüg- 
gő karakterhalmaz, így csák egy egyezést tapasztalunk. A má- 
sodik sorban úgyszintén. 

Ezzel szemben RegexOptions.Singleline módban a sorvégi 
újsor (In) karakter nem állítja meg a motort, így a sorokon 
átívelve is egyezést talál a 2.......€-: 





A második egyezésben benne van az első sor ,r" betűje, a 
skocsivissza-soremelés" páros és a ,Máso" karakterek. 

A pontot nagyon gyakran fogjuk arra használni, hogy ismeret- 
len szövegre állítsunk fel egyezéseket. A következőkben sok 
példát fogunk látni a használatára. 


Pozícionális karkterek (Anchors vagy Atomic Zero-Width 
Assertions) 


Az eddig látott karakterosztályok, jokerek mindig helyet 
fogaltak el, azaz miután a regex motor egyezést talált, tovább- 
lép egy karakterpozícióval mind a forrásszövegben mind a 
regexben, és onnan keres a regex maradékára egyezést. Pél- 
dául a 2.t.€ esetén ítesztsztring: Született ma) az első 2.€ 
talál egy karaktert, az ,S"-t, majd a motor továbblép a 
regexben a 2t€-re, és megnézi, hogy az illeszkedik-e a so- 
rok következő karakterre, a ,2"-re. Mivel nem, eldobja ezt a 
próbálkozást, és továbblép a forrásszövegben a ,27-re, vissza- 
tekeri a regexet az elejére, és nekiáll a 2.€-ot újra ráilleszte- 
ni az ,ü" karakterre, stb. 

Azaz a lényeg, hogy a normál karakter vagy karakterosztály 
egyezések helyet foglalnak el, továbbléptetik a forrásszöveget. 
Ezzel szemben a pozícionális karakterek nem foglalnak el he- 
lyet, csak kijelölnek egy pozíciót a forrásszövegben, aminek 
teljesülni kell ahhoz, hogy egyezést kapjunk. 

A 356 (kalap) a szöveg vagy sor elejét jelenti. Alapban szö- 
veg elejét, RegexOptions.Multiline esetén a sor elejét. Azaz a 
multiline üzemmódban a regex motor soronként dolgozza fel 
a szöveget, hasonlóan a grep-hez. (A normál eset a sed műkö- 
déséhez hasonló.) 


Normál mód: 





A második példa csak azokra a sorokra mutat egyezést, ame- 
lyekben pontosan és csakis az , alma" szó szerepel: 








minden sorra egyezést mutat (multiline módban), azaz nem 
túl praktikus regex. Habár, ha ezzel a kifejezéssel szétszedünk 
darabjaira egy szöveget, sorokra bontva kapjuk vissza. Mond- 
juk ennél egy String.Split egy cseppet gyorsabb lenne, de ezt 
azért még lehet tovább alakítani, például szűrni a sorokat. 





az üres sorokat válogatja ki, amikben még whitespace sincs 
(természetesen ez is multiline módban működik jól). 

A 29E szóhatáron egyezésre való. Szóhatár a 2w€ és 
3 WWc6 átmenet, tetszőleges irányban, így a 24b€ szó ele- 
jének és végének keresésére is jó. 

Baloldalt behatárolt ,al" sztring: 








AZVWE olyan mint a 39€, csak mindig a szöveg és nem a 
sor elejét jelenti függetlenül a multiline opciótól. 

AJN€ (figyelem, kis z) pedig olyan mint a 2$€-, csak min- 
dig a szöveg és nem a sor végére mutat egyezést. 

A91€ (nagy 7) annyival engedékenyebb, mint a kisbetűs 
párja, hogy a szöveg végén még lehet egy plusz soremelés is. 
Ez amúgy igaz a 2$€-ra is. 


tech.net 


Vannak még további pozícionális kifejezések is (pl. (?!...)), 
amelyekre most terjedelmi okokból nem térek ki. [6] 
mindegyiket tárgyalja. 

Pozícionális karktereknél nagyon oda kell figyelni, hogy 
Windowsban a sorok vége nem Mn, hanem Wim, ami miatt 
sokszor nem jól működnek a Unixon helyesen zenélő 
regexek. Agyrém, de erre fel kell készülni. 


Számosság (Ouantifiers vagy Modifiers) 


Amit eddig láttunk, az csak a jéghegy csúcsa. A regexek első 
igazi erőssége a számosság adta flexibilitás. 

Miről is van szó? Az 2a€ egy darab a betűt jelöl, fogyaszt el. 
Az 2a?€ (,a" betű, utána egy kérdőjel) viszont azt jelenti, 
hogy az ,a" karakter 0 vagy egyszeri előfordulása. Ez azt je- 
lenti, hogy akkor is egyezést mutat, ha az adott pozíción van 
va" betű, de akkor is, ha nincs. Azaz a kérdőjel jelentése: az 
előtte levő karakter vagy karakterosztály opcionális. 

Az alábbi példa törtszámokat próbál meg elcsípni, a tört rész 
opcionális: 


AJ3N€ a pont karaktert jelöli, csak mivel az metakarakter, 
meg kellett védeni egy visszafele perjellel. Látható, hogy csak 
az első két számjegy kötelező, az utána következő karakterek 
nem. Sajnos ez a regex megengedi a ,15."-t is, ami nem sza- 
bályos. Amíg nem ismerjük a csoportosítást, addig ezen nem 
tudunk segíteni. 

A 27-€ 1 vagy több (legalább 1) előfordulást jelöl. A példa az 
összefüggő számsorokat keresi meg: 


A 3"€ 0 vagy több (bármennyi) számosságot definiál. A 
ponttal együtt használva könnyedén leírható a bármiből bár- 
mennyit minta: 








Ha belegondolunk, ez a minta mindenre egyezik még az üres 
sorra is, és a bármilyen karaktereket tartalmazó sorokra is. 
További számossági jelzők is léteznek. A 2(n1€ jelentése: 
pontosan n előfordulás. A példa három összefüggő betűt 
keres: 





Azaz nem hárombetűs szavakat keresünk, ahhoz be kell vet- 
nünk a szóhatárt is, mindkét oldalról: 





2In)€: legalább n találat. Minimum 3 digites egész számok 
keresése: 





tecn 


Láthatóan a tizedes tört utáni részt is megtalálja. Hogy azt ki- 
szűrjük még okosítani kell a regexünket (2(?aN.JAd[3,] €-, az 
érdeklődők kedvéért :) . 


És végül a 3(n.m) € legalább n, de legfeljebb m darabszámot 


- 
e. 
a 


- Hasazalapty stiernőag , 1340 [a01a1 


Az összes eddig látott számosságjelző mohó, azaz megpróbál 
olyan hosszú egyezést összehozni amennyit csak lehetséges. 
Például a 21w(3,1€- megpróbálja a lehető leghosszabb, de 
minimum három karakter hosszú betűcsoportokat megtalálni: 





Azért mohó, mert nem elégszik meg a minimálisan megköve- 
telt darabszámmal. 

Bármelyik számosságjelző mohóságát elvehetjük, ha mögé ra- 
kunk egy kérdőjelet: 





Látható, hogy most megáll a feltételt minimálisan kielégítő 
számú karakternél, aztán folytatja a keresét. Ezért vágta ketté 
a kecskét. 

Gyakoroljuk kicsit az eddigieket! Hogyan keresnénk meg a ki- 
kommentezett sorokat (// Ctt kódban? 


layyaxaőai JETIOYEÁŐ sa jalauja sezobropjajbanozs 


Hogyan gondolkodunk? Soreleje, majd jön utána akárhány 
darab whitespace, majd két egymás utáni perjel, aztán a 
sorvégéig bármi. Elég könnyű lefordítani regexre: 


§ 
§ 
8 
É 
VO 
: 
d 


Következő hatalmas fegyverünk a csoportosítás, melyet záró- 
jelezéssel érünk el. Többféle okból csoportosítunk: 


AA a csoportokra használhatunk számossági jelzőket 

AA a csoportok által megfogott tartalomra hivatkozhatunk 
a regex többi részében (backreferences) 

A a csoportok által elkapott tartalmat kinyerhetjük prog- 
ramozott eszközökkel 


GI 
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Mivel a számosság használható csoportokra, a korábbi tört- 
számokat kereső regexünket mostmár tökéletesre írhatjuk: 





Magyarra fordítva: minimum egy decimális számjegy, aztán 
egy opcionális csoport, ami belül úgy néz ki, hogy egy pont, 
aztán minimum egy számjegy. Azaz csak akkor fogjuk meg az 
egész rész után álló pontot, ha utána van számjegy, egyébként 
nem. 

Egyszerű, de nem teljes email ellenőrző: 


3NwraVwr(V.Awr)r6 
sociGnetacademia.net, almasesexybabes.com 
socil2Galma.korte.neta.com 


Visszahivatkoz41 eferences) 


Tegyük fel, hogy html tagok közötti kifejezéseket akarunk leír- 
ni regexszel. Első nekibuzdulásunkban megszüljük ezt: 


3 wit [Nwts] $c/ wir: 6 
ch1salmac/h1l2 és ch25 körte c/h22 cp2:c/p2 


Az eddigiek alapján ennek teljesen érhetőnek kell lennie. Igen 
ám, de ez könnyen átverhető: 


chi. £/xxx: - hibás! 


Megeszi ezt is. Valahogyan meg kellene mondani, hogy a má- 
sodik kacsacsőrös részben azt akarjuk látni, amit az elsőben 
elkapott a regex motor. 

Ehhez először be kell zárójeleznünk az elkapandó kifejezést: 


7 c(Nwr)3[Wwvs]te/Nwr: 


Ez nem változtat semmit a kifejezés működésén, de a regex 
motor már tudja, hogy valami célunk van a zárójeles kifeje- 
zéssel, ezért megjegyzi azt. 

Már csak az a dolgunk, hogy a zárótagnál hivatkozzunk a zá- 
rójeles tartalomra. Erre való a visszahivatkozó kifejezés: 


c(Nw4)3[Nwis]tc/N1s 
ch1lsalmac/xxx:; és ch23 körtec/h25  cp:c/p2 


A3V € azt jelzi, hogy itt olyan tartalmat várunk el, amit a 
balról legelső zárójeles kifejezés fogott meg. Fontos megje- 
gyezni a szabályt, balról az n., mert egymásba ágyazott záró- 
jelek esetén így könnyű megtalálni mire akarunk hivatkozni. 
Az 3026 a második, kifejezésre hivatkozik. A visszafelé 
hivatkozás hatalmas lehetőség a regexekben, és ilyet csak az 
NFA motorok tudnak, ezért aztán a legtöbb engine NFA. 





Elágazások (Alteration) 


Ha a karakterosztályoknál megadhattunk választást egy karak- 
terpozíción, akkor ezt miért ne tehetnénk meg nagyobb regex 
kifejezésekre is? Erre való az elágazás, melyet a 21€- (pipe, 
cső, függőleges vonal) szimbólum reprezentál. A következő 


regex jelentése: , alma" vagy ,körte" karakterek egymásutáni- 
sága: 


7J3almalkörte€6 Í 
alma, körte, körtealma, cser, hatalmas - 5 egyezés 


Sokféle kommentet kereső kifejezés: 


39 st(/zltlreml").1$€ 


int i; 
//long a; 
: dim i as Integer 
B al di nt 


4 unix comment 


Az elágazások bármelyike lehet összetett regex is. A követke- 
ző példa által ellenőrzött értékek behatárolását a kedves olva- 
sóra bízom. 


7 VboNdatbilNbitdatbi 1b2[0-3]1b6- 
15, 28, 21, 14, 5, 142 
Gondolkodtató példák 


Exponenciális számokat felfedező regex: 


3((Mdr) PV.) ?tdre[r-]?idr€ 
3e8, 4et4, 5e-B, 45.6e-5, .34e-6 


Fájl elérési útból a fájlnevet kiszedő kifejezés: 
DAN ASET 


/winnt/system32/drivers/etc/lmhosts.sam 


Mohó számosság esetén az első ." felemészt mindent, a má- 
sodik kifejezésnek csak a legutolsó szakaszt hagyja meg: 


DAC EJ ÉJSE 
wi: 2 iveri XI 
0 -5 winnt/system32/drivers/etc 


1 -5 hosts.txt 


A mohóságát csillapítva megelégszik az első /-ig tartó legrövi- 


debb kifejezéssel: 


DAC AEROB E 
winnt/system32/drivers/etc/hosts.txt 


0 -5 winnt 
1 -5 system32/drivers/etc/hosts.txt 


Mi történik, ha a második csillag mohóságát is elvesszük? 
Semmi változás nem történik, mert miután az első kifejezés 
önmegtartóztató módon csak a ,winnt" karaktersorozattal 
egyezik, a második minden visszafogottsága ellenére kényte- 
len elvinni a többit. 

És a teljesség kedvéért: ha az első mohó a második nem, az 
első felszed mindent az utolsó perjelig, így a második kapja a 
maradék részt, ha mohó, ha nem. 

Html tagek kitakarítása, például fórum szoftverekhez: 


7Z/?Nwrlt5]t5€ 
chtml:chead: 
f 2 0 0 3 b d 


clink rel-"stylesheet" type-"text/css" 
href-"/css/main.css"5 
ctitlesNetAcademia - A legjobbakat 
tanítjukc/titles 

c/head: 

cb:Tanfolyami térképek:c/b:cbr: 
c/html: 


Az eddigiek után a kiinduló példánkban szereplő regex már 
gyerekjáték kell legyen: 


Vol Nwr) (NsIc[55]4$5)4(N1)1b6 


Ha nem, akkor érdemes újra elolvasni a cikket, és tesztprog- 
ramokkal ([4] és [5]) próbálgatni a kódokat (leglább kiderül, 
mennyi bug maradt benne :). Ez a leggyorsabb módja a regex 
tanulásának. 

Utolsó példaként tetszőleges szepatárorokkal elválaszott, de 
év-hó-nap formátumú dátumok megtalálását nézzük meg: 


-NDH(Ndtvdtdta) ND(Ndta) ND(Ndtd) Dr €- 


Hogy ezen példát hasznunkra tudjuk fordítani itt az ideje, 
"hogy megnézzük programozott módon hogyan lehet elérni a 
regex szolgáltatásokat. 


Regex programozás a .NET Frameworkben 


Kiinduló oszályunk a System.Text.RegularExpressions.Regex 
lesz. Ez képes eltárolni egy regexet, amit aztán rászabadítha- 
tunk egy sztringre. 

Létrehozásakor megadhatjuk a kívánt regexet stringként, illet- 
ve a működési opciókat a RegexOptions enumerációs típus 
segítségével: 


RegexOptions options - RegexOptions.lIgnoreCase; 
Regex regex - 

new Regex(e"YVb(Wwr)(VsIc(55142)r(M1)Nb", 
options) ; 


Esetünkben lényeges, hogy a kis-nagybetű különbség ellenére 
két szót azonosnak tekintsünk, ezért a 
RegexOptions.IgnoreCase opció. 

A regex által elkapott darabokat a következőképpen kaphatjuk 
meg: 


MatchCollection matches - regex.Matches(input); 


Az input a bemeneti stringünk. Az eredményeken könnyű vé- 
gigiterálni: 


foreach(Match match in matches) 
f 
Console.WriteLine("Pos: (0) ", match.Index); 
console.WriteLine("1. szó : (0) ", 
match.Groups[1]); 
cConsole.WriteLine("Ismétlés: (0) ", 
match.Groups[3]); 


A MatchCollection az összes megtalált kifejezést tartalmazza. 


Ezeket egyedi Match objektumokként érhetjük el a ciklusban. 
Minden egyes Match tartalmazza azt a szöveget, amit a regex 
elkapott. A Match.Index az egyezés pozícióját adja vissza a 
bemeneti szövegben. 

Nekünk csak az első és a harmadik zárójeles kifejezés az ér- 
dekes, a középső nem, annak csak az volt a dolga, hogy le- 
nyelje a két szó közötti html tagokat és whitespace-eket. 
Szerencsére a zárójelezett tartalmakat közvetlenül elérhetjük 
a Match objektum Groups kollekcióján keresztül. 

A 0. csoport mindig a teljes Match-et tartalmazza, ezért az el- 
ső zárójeles regex (2w-HJ€-) által elkapott tartalmat az első 
Group elemben érhetjük el: 


Console.WriteLine("1. szó : (0) ", 
match.Groups[1]); 


Értelemszerűen a 3. csoport a match.Groups[3] mögött lesz. 
Mit találunk a második csoportban? Nos, ez csak az igazán ér- 
dekes. 


3(NsIc[95]45)1€ 


Ez a csoport akár többször is szerepelhet az egyezésben, ezért 
ezt nem lehet egyszerűen match.Groups[2]-ként elérni. 

Ha a bementi sztring 

Ez is cisdadogásnakc/is:  cusDadogásnakc/u: számít. 
akkor a match.Groups[2].Value-ban ,cus"-t találunk. Pedig 
ha belegondolunk, a második csoport 4-szer is működött: egy- 
szer elkapta a "d/is"-t (2.x.[15]-5€-), aztán egy szóközt 
(2156), aztán mégegyet, majd a ,cu2"-t. A Value jellemző 
csak az utoljára elkapott darabkát adja vissza! 

Az összeset a csoport Captures jellemzőjén kereszül szedhet- 
jük elő: 


int i z 07 
foreach(Capture c in match.Groups[2] .Captures) 
1 

Console.WriteLine("(0).: (1)", it4, c.Value); 


0.3 e/15 
1.: 
2.2 
3.: cus 


A dátumnormalizálós példánkhoz az elkapott csoportok tar- 
talmából kell összeállítani egy formázott dátumot, és azzal 
kell kicserélni a talált, rosszul formázott dátumnak látszó 
sztringet: 


private void Run() 
fi 
string[] dates - 
( 
"2003/08/12", 
"2003.08.12", 
"2003.O8ZT2 És sg 
"aa2003/08.127" 
1; 
foreach(string d in dates) 


. Hasazalarig SIR In bay / 
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A cserét a Regex.Replace hajtja végre. A $n kifejezésekkel az 
n. elkapott csoportra hivatkozhatunk, hasonlóan a visszahi- 
vatkozások 2m€--jéhez. 

A következő példa hyperlinkeket gyűjt ki egy html lapból. A 
találatokat most alternatív módon érjük el: 





Ez utóbbi módszer előnye, hogy a regex egyeztetés lépésen- 
ként megy végbe, így a ciklusból idő előtt kilépve a maradék 


részen nem kell dolgozni a motornak. 


Zárszó 


Az eddigiek megértése után gyarkorlati munkák előtt még ér- 
demes áttekinteni a .NET Framework regexekkel foglalkozó 
fejezetét [6], ugyanis jóval gazdagabb csoportosítási lehetősé- 
gek is vannak még, mint amelyekről a cikkben olvashattak. 
Jó regexelést! 


Soczó Zsolt 

zsolt.soczofgoönetacademia.net 

A szerző a NetAcademia vezető fejlesztési oktatója, 
MCSE, MCDBA, MCSD.NET, MCT 


A cikkben szereplő URL- 


(11 http://www.unicode.org/ 

12] http:/Awww.unicode.org/reports/tr8/index.html 
13] http://tinyurl.com/gw7c 

14] http://www.sellsbrothers.com/tools/fregexd 
15] http://tinyurl.com/nyof 

16] http://tinyurl.com/atlv 
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A tanfolyami jelentkezéseket a tanfolyam kezdete előtt 1 héttel lezárjuk. 





Megrendelő cég neve: 





Résztvevő(k) neve: 





Számlázási cím: 





Telefon / Fax szám: 





E-mail cím 





.] Tanfolyam neve és 
kódszáma: 





Tanfolyam időpontja: 





Tanfolyam díja: 


(tartalmazza a tananyag és 
az ebéd költségét) 














A tanfolyammal kapcsolatos változtatások jogát fenntartjuk. 


Lemondás: A tanfolyam a kihirdetett kezdési időpontot megelőző 14 naptári nappal mondható le 
díjmentesen. A tanfolyam kezdetét megelőző 14-3 naptári napig lemondás esetén a tanfolyami díj 8099- 


át térítjük vissza. A kezdetet megelőző 3 naptári napon belül lemondást nem áll módunkban elfogadni. 


Honnan értesült a tanfolyamról? 


L] NetAcademia hírlevélből 


Vegetáriánus ebédet kér? 





LI Igen 


Dátum: 


Pecsét 





LI] Katalógusból LI Kollégától  LI] tech.net magazinból L] Egyéb 


(I Nem 


Cégszerű aláírás 


H-1062 Budapest, Andrássy út 62. e Tel.: t 36 1 472 1214 e Fax: 436 1 472 1215 e E-mail: info DnNetacademia.net 


http://vww.netacademia.net 


Menjen biztosra! 


Az alábbi tanfolyamaink biztosan indulnak. 
Jelentkezzen, amíg vannak szabad helyek! 


A SZÁMALK Továbbképzésnél 
az őszi/téli időszakra még több 
mint 10, különböző témakörű 
képzésből válogathat, a 
Windows 2000 témáktól 
kezdve a szerver termékeken 
át a fejlesztőeszközökig. 


November 10-14.: SOL Server 2000 adatbázis implementáció és programozás (2073) 
November 17-21.: Windows 2000 rendszeradminisztráció (2126) 

November 24-25.: SOL Server 2000 alapok, lekérdezések, Transact SOL (2071) 

November 24-28.: Windows 2000 hálózatinfrastruktúra üzemeltetés (2153) 

November 26-28.: Adatkezelés Visual Studio .NET-tel (2389) 

December 1-5.: Exchange Server 2000 üzemeltetési ismeretek (1572) 

December 1-5.: Windows 2000 üzemeltetési ismeretek (2152) 

December 1-5.: Web alkalmazások fejlesztése Visual Studio .NET-tel (2310) 

December 8-12.: SOL Server 2000 üzemeltetés, adatbázis adminisztráció (2072) 
December 15-19.: Windows 2000 Active Directory adminisztráció és tervezés (2154--1561) 


2004. január 26-30.: Windows alkalmazásfejlesztés Visual Studio .NET-tel (2555/2565) 
2004. február 23-27.: Web alkalmazások fejlesztése Visual Studio .NET-tel (2310) 
2004. március 22-24.: XML webszolgáltatások fejlesztése Visual Studio .NET-tel (2524) 


A kínálat frissülhet és változhat, kövesse 
nyomon internetes tanfolyamlesünket! 


VAA ee ta TTL TÁ yZe 


Microsoft 
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Professional 


Microsoft 
CERTIFIED 


Technical Education 
Center 


Tel.: 203-0304/3050 (Simon Ferei 
1115 Budapest, Etele út 68. 





